ABRL Writer Help
1.
|
INTRODUCTION
|
5.
|
ADVANCED
|
1.1
|
5.1
|
||
1.2
|
5.2
|
||
1.3
|
5.3
|
||
1.4
|
5.4
|
||
1.5
|
5.5
|
||
1.6
|
5.6
|
||
1.7
|
5.7
|
||
1.8
|
5.8
|
||
1.9
|
5.9
|
||
1.10
|
|||
6.
|
INTEGRATIONS
|
||
2.
|
GETTING STARTED
|
6.1
|
|
2.1
|
6.2
|
||
2.2
|
6.3
|
||
2.3
|
|||
2.4
|
7.
|
ASSURANCE
|
|
2.5
|
7.1
|
||
2.6
|
7.2
|
||
2.7
|
7.3
|
||
2.8
|
7.4
|
||
2.9
|
7.5
|
||
2.10
|
7.6
|
||
2.11
|
|||
2.12
|
8.
|
MISCELLANEOUS
|
|
2.13
|
8.1
|
||
8.2
|
|||
3.
|
FORMATTING
|
8.3
|
|
3.1
|
8.4
|
||
3.2
|
|||
3.3
|
|||
3.4
|
|||
3.5
|
|||
4.
|
DATA
|
||
4.1
|
|||
4.2
|
|||
4.3
|
|||
4.4
|
1. INTRODUCTION
|
In this Chapter we introduce ABRL Writer, what it is and how to access the software and report building resources.
ABRL Writer ("Writer") is a specialized Inline XBRL (iXBRL) word processor, designed to help you efficiently create, edit, and visualize structured business reports using the Extensible Business Reporting Language (XBRL) standard. Whether your focus is financial statements or sustainability reports, Writer ensures your work is both precise and compliant.
What is iXBRL?
iXBRL combines the best of two worlds: it’s a format that integrates human-readable content with machine-readable data in a single document. This approach builds on traditional XBRL, which focuses primarily on machine-readability, by adding a layer of usability that’s accessible to a wider audience.
Understanding XBRL
At its foundation, XBRL is a globally recognized open standard for the digital exchange of business and financial information. It was developed to enhance how financial and business data is prepared, analyzed, and shared—providing consistent and efficient reporting for organizations, regulators, investors, and other stakeholders.
The Role of Taxonomies
iXBRL reports are built using an XBRL taxonomy, a structured dictionary that defines the elements and relationships within digital business reports. These taxonomies ensure data is consistently reported and interpreted. Regulatory authorities and standard-setting organizations typically maintain and update these taxonomies to reflect current reporting requirements.
Tagging and Intelligent Reporting
In iXBRL, each report element is tagged with corresponding taxonomy elements, enabling software to interpret and analyze the data. This process ensures that reports are not only visually clear but also machine-readable, bridging the gap between presentation and data processing.
Why Choose Writer?
Writer seamlessly incorporates XBRL taxonomies into your workflow, enabling you to produce high-quality financial and sustainability reports with precision and clarity. It’s an essential tool for anyone tasked with creating structured business reports in today’s digital reporting landscape.
The Report Writer offers two modes to suit your reporting needs:
1. Paper-Based Mode: In this traditional approach, all data is directly entered on the face of the document, much like filling out a static form.
2. Digital-First Mode: This modern approach uses dynamic variables to represent values that change from one reporting period to another. In this mode, a clear distinction is made between numeric variables (e.g., financial figures) and non-numeric variables (e.g., dates or descriptions). Additionally, static content—such as layout details, titles, headers, and accounting policies—remains an integral part of the document.
Why Choose Digital-First Mode?
The digital-first mode is the preferred choice for its efficiency and accuracy. It helps streamline reporting by reducing manual updates and minimizing errors. With Writer, you can easily:
• Structure your data for clarity.
• Organize information in well-designed tables.
• Visualize data to enhance understanding and usability.
These features make reports not only easier to create but also more insightful for readers.
Mixing Modes
You’re not restricted to using a single mode. Writer allows you to seamlessly combine the two approaches, offering the flexibility to cater to different sections of your report. For instance, static data can be managed in paper-based mode, while dynamic variables power your data-driven sections.
1. INTRODUCTION
|
Writer integrates with XBRL taxonomies to tag report elements by reference to reportable facts listed in the taxonomy. In addition to linking an item by name, by context and by unit of measure, the report writer also allows dimensional characteristics to be attributed to document elements, be they static or dynamic.
Unlike many XBRL tagging software products, Writer requires tags to be associated with report elements at preparation stage rather than after the report has been produced. The process of this tagging up-front introduces a new discipline to report preparation. It forces the report author to consider each element in the context of how it is defined and presented in the taxonomy e.g. is the element defined to have a debit or credit balance by default?
As taxonomies are standards based this aspect of the approach to tagging also challenges the report author to consider the adequacy of disclosure, be it too much or too little, or even if it is required at all.
The digital-first approach ensures a better quality product that is easier to maintain as standards evolve with reduced ongoing maintenance costs.
We package XBRL Taxonomies for use with Writer and make these packages available for download free from our website. We can do this for XBRL compliant taxonomies that include a presentation view.
As well as taxonomies that are publicly available, we can package and host private taxonomies in our private taxonomy library. Only users provided with a link can download a taxonomy from this library.
It should be noted that the report writer targets financial and sustainability reporting taxonomies and not data point model based ("DPM") taxonomies used by banking and insurance regulators. These latter taxonomies are more suited to a document that follows a spreadsheet based paradigm.
(NOTE: Please do not hesitate to ask us to package a taxonomy that is publicly available it is not present in the taxonomy library. We are prepared to do this at no cost.)
1. INTRODUCTION
|
Illustrative report specifications for a selection of taxonomies are published and can be downloaded and used free of charge. These specifications can form the basis for developing new reports or understanding how reports are built.
As no two sets of financial statements or sustainability reports are ever the same in terms of disclosure or presentation, ABRL offers report authoring services to create open reports. Open reports are reports that are not predefined and fixed, and can be customized to suit the needs of the organization.
In contrast, closed reports are predefined and fixed reports where the data points and layout of the report are predefined and fixed. Examples of closed reports are tax schedules and analyses required by revenue authorities. Selected examples will also be published.
When crafting report specifications, we employ a sophisticated method known as scripting, wherein the design is articulated through lines of code. This approach not only streamlines the report authoring process but also opens the door to seamless integration of artificial intelligence (AI). By encapsulating the design in code, we empower ourselves to harness the capabilities of AI, enhancing the efficiency and precision of our reporting endeavors. XBRL taxonomies, and published reports in the XBRL format, in particular, can serve as training material for AI.
Furthermore, the use of scripting promotes code re-usability, fostering a modular approach to report creation. This modularity allows for the assembly of intricate reports from simpler, well-defined component parts.
In essence, scripting serves as the backbone that not only expedites the report authoring workflow but also lays the foundation for scalable and adaptable reporting systems.
Please contact us for further information.
1. INTRODUCTION
|
Did you know XBRL comes in two distinct flavors? The first is Raw XBRL-XML, also known as an XBRL Instance. Think of it as the behind-the-scenes data powerhouse—packed with information but completely illegible to humans. On the other hand, there's iXBRL, the star of the show and the format Writer produces as its primary output. iXBRL strikes the perfect balance: it's human-readable for users like you while retaining machine-readability for automated processing.
So how does Writer make this happen? When you process a report, Writer takes three key steps:
1. It starts by creating a raw XBRL-XML data file.
2. Separately, it generates a clean, structured XHTML document.
3. Then, the magic happens—it merges these two, incorporating your input along the way, to produce a single, seamless iXBRL document.
To keep things simple, the raw XBRL-XML file is deleted after processing. This avoids any potential confusion, especially since there are subtle differences between raw XBRL-XML and iXBRL when dealing with large blocks of tagged narrative text.
With Writer, we prioritize having a single source of truth. That’s why formats like PDF and MS Word reports are generated directly from the iXBRL output. While these formats are convenient for review and distribution, they don’t include the XBRL tags, highlighting the difference between the intelligence of iXBRL and the others closer relationship with paper.
This document has been prepared using ABRL Scripting and visualised in Writer. The document is not intended to be an exhaustive explanation of how the software works but provide sufficient guidance to a report author on how to produce professionally tagged digital reports leveraging XBRL technology and taxonomies.
The Full IFRS Taxonomy for 2023 (IFRS_AT_FULL_2023) was used in creating the examples provided in this document. This taxonomy (or a compatible updated version) ships with the standard software install.
A trial version of the software can be downloaded from [Website Software Download].
2. GETTING STARTED
|
An XBRL Taxonomy defines and categorises elements to be used in a report. The Taxonomy can be presented as an easy navigable dictionary of reportable facts. The taxonomy in use by a report can be accessed on the Taxonomies tab of Writer as shown below:
In order to use Writer you MUST use it with a taxonomy that has been packaged for use with the software. Packaged taxonomies can be found on the ABRL website at [ABRLTaxonomy Download URI].
If the taxonomy related to your reporting requirements is not published on the ABRL website and is publicly available then please message us at [ABRLServices EMail] with a link to the taxonomy. We will compile and publish on the ABRL website.
TIP: When a taxonomy us downloaded use the "Deploy Downloaded Taxonomy" option in the help menu in Writer. This will place the taxonomy in a user application data folder created when the software was installed.
2. Getting Started
|
A new report is created by selecting a taxonomy that has been downloaded and deployed to the folder that is selected by default for the user. A blank document will be presented and the taxonomy will appear in the taxonomy tab of the information pane. The following steps then need to be followed:
1. Select the currencies tab an add one or more reporting currencies.
2. Select the datasets tab and add reporting periods, associating each with a currency.
3. Assign required properties to each dataset added, e.g. scale and decimals.
3. Read basic rules below before starting to type anything into the document.
That is all there is to it. Alternatively check out the ABRL website and see if there is an illustrative report specification available for your taxonomy and save yourself lot of time and effort. See [ABRLIllustrative Reports].
In the exhibit below the datasets used in the preparation of this document are shown:
Exhibit 1
|
TIP: It is best to assign dataset periodRef numbers in sequence starting at a value of 1.
TIP: The folder where downloaded taxonomies are located can be viewed by selecting Help --> Show Taxonomy Folder.
2. GETTING STARTED
|
More than just a word processor. In addition to a document editor, the report design pane includes tabs for dataset definition, currency selection and relationship building. Authoring and editing digital business reports is a many faceted process:
Writer is fundamentally a word processor that has been enhanced to create, edit and format financial statements and other business reports including sustainability reports. Writer does this by being be aware of, and understanding, XBRL taxonomies.
The report author can start typing by just entering text, applying formatting to document elements, adding tables and populating cells with values without ever referring to the taxonomy. The application will behave just like a word processor in this scenario.
Writer loves tabular data. It is easy to add tables and insert dynamic variables that are used as placeholders for data that can be imported or entered manually and resolved at run-time. Much like fields in MS Word.
The report author can go one major step further than MS Word and link cells in the tables to XBRL taxonomy elements. Writer fully supports additional characterisation of report elements using XBRL dimensions.
The primary output format, the single source of the truth, is iXBRL. PDF and Word representation of report output are derived from the iXBRL. This is not your ordinary word processor that uses a paper based paradigm. This is a special, digital-first word processor and report writer.
2. GETTING STARTED
|
Understand and remember the following basic rules and everything else will fall into place and be more easily understood:
1. ONLY TABLE CELLS CAN BE TAGGED
2. DATA INPUT VALUES FOR ITEMS WITH DEBIT BALANCES ARE POSITIVE, CREDIT BALANCES ARE NEGATIVE
3. OUTPUT FOR AN ITEM WITH A BALANCE THE SAME SIGN AS ITS XBRL BALANCE ATTRIBUTE WILL BE POSITIVE
4. OUTPUT FOR AN ITEM WITH A BALANCE THE OPPOSITE SIGN OF ITS XBRL BALANCE ATTRIBUTE WILL BE NEGATIVE
5. MONETARY AND NUMERIC VALUES ARE ALWAYS ENTERED AS THE ACTUAL AMOUNT, NOT A SCALED AMOUNT
6. VALUES FOR DATES AND DATE DERIVATIVES MUST ALWAYS BE ENTERED AS YYYY-DDDD-MM
7. PERCENTAGES ARE ENTERED AS A FRACTIONAL AMOUNT
8. BOOLEAN VALUES ARE EITHER TRUE OR FALSE
RULE 1: ONLY TABLE CELLS CAN BE TAGGED
The implication of this first rule is that data is almost exclusively presented in tables. This is not surprising as structured business data is tabular by nature. Some reporting accountants may not be entirely happy as important data is often buried in narrative which may now need to be disclosed in a table if it is to be tagged. Reports are consequently more transparent.
In the extract from a financial statement below the table cells that are tagged are highlighted:
Exhibit 2
|
2. GETTING STARTED
|
RULE 2: DATA INPUT VALUES FOR ITEMS WITH DEBIT BALANCES ARE POSITIVE, CREDIT BALANCES ARE NEGATIVE
Rule2 affects data entry and imported data. It only affects monetary items where XBRL default balance attributes i.e. Dr. or Cr. have been set in the taxonomy. Writer follows the standard industry practice of representing debit balances with a positive value and credit balances with a negative value.
TIP: When entering negative data values as static data on the face of the document use a minus sign and not brackets.
RULES 3 & 4: OUTPUT VALUES, BALANCE AND SIGN
Rules 3 and 4 determine how output values are computed. When the data is processed and the balance for a monetary item has the same sign as its attributed XBRL balance then the XBRL output will have a positive value. If the balance has the opposite sign, then the value output will be negative.
The third and fourth rules result in the following consequences:
• A debit item with a debit balance will be output as a positive number.
• A credit item with a credit balance will be output as a positive number.
• A credit item with a debit balance will be output as a negative number.
• A debit item with a credit balance will be output as a negative number.
For example a profit will be output as a positive number, a loss as a negative number.
These rules may cause difficulty when it comes to displaying items. For example, the report author may want to display cost of sales in an operating statement as a bracketed "negative" number even though its value is positive. Adding or removing brackets is achieved by setting a reverse display-sign flag as discussed below.
RULE 5: MONETARY AND NUMERIC VALUES ARE ALWAYS ENTERED AS THE ACTUAL AMOUNT, NOT A SCALED AMOUNT
This rule is not unique to Writer, it is a core XBRL rule that is commonly misunderstood. Values must be captured as the actual full (original value) and not after they have been scaled/transformed in some way such as into thousands, millions, billions, etc.
XBRL provides a decimals attribute to describe how accurate a number is to the reader. iXBRL provides an additional attribute scale that informs the reader how the original number has been transformed for display e.g. into thousands, millions, etc. or not at all.
Decimal precision and scale are discussed below and display format in the section on formatting.
RULES 6 & 7 & 8: DATES, PERCENTAGE AND BOOLEAN
See the section on formatting below for a description of how to format dates which can only be entered as YYYY-MM-DD values. Examples are also provided for formatting percentages and boolean values.
2. GETTING STARTED
|
Basic tagging involves associating a value in a table cell with a reportable fact in the taxonomy. In the iXBRL report output the tag information will be included behind the scenes and invisible to the human reader. The following are the steps required to tag a table cell:
1. Insert a table into the document with 2 rows and 2 columns.
2. Navigate the taxonomy and select a numeric element that represents Revenue.
3. Paste label into the first cell in row 1, column 1.
4. Put -1,000 as a value in row 1, column 2. Align the value to the right.
5. Drop down the Datasets(Reporting Period) combo and select a period.
6. Tag On.
Below is an example of the report specification and the output. There is a subtle but very significant difference between the input and output: the output displays the amount entered as a credit balance as a positive in accordance with rule 3 above.
Exhibit 3. - Basic Tagging - Design
|
||
Revenue
|
-1,000
|
|
Exhibit 3. - Basic Tagging - Output
|
||
Revenue
|
1,000
|
|
The hidden tag information in the iXBRL report can be inspected in the browser and can be seen below:
2. GETTING STARTED
|
Numeric variables can be accessed in the Numeric Data tab as shown below:
Exhibit 3 above can be enhanced to incorporate a dynamic numeric variable as follows:
1. Replace the value of -1000 with #Revenue. The" #" flags this as a numeric variable.
2. Proceed to Edit --> Update --> Numeric Variables (The application should inform you that 1 numeric variable record was added).
3. Navigate to the Numeric Data tab and confirm that Revenue has been added for period P20X1.
4. Proceed to Data --> Data Entry and enter -1000 as a value for Revenue. Save to Report.
5. Proceed to File --> Reports and view the iXBRL report. Note that the value is output as positive as the system knows this is a credit balance for an item defined to have an XBRL balance attribute of credit.
Exhibit 4. - Numeric Variable - Design
|
||
Revenue
|
#Revenue
|
|
Exhibit 4. - Numeric Variable - Output
|
||
Revenue
|
1,000
|
|
TIP: Although numeric variables must appear alone in a cell when they are being tagged, they can also appear anywhere in a document and in conjunction with other text. Just remember to specify the period reference in brackets after the identifier or the value will be taken to be period 1. For example in report design "the value for revenue is #Revenue(1)" will resolve to "the value for revenue is (1,000)".
2. Getting Started
|
Non-Numeric variables can be accessed in the Non-numeric Data tab as shown below:
Revenue as disclosed in exhibit 1 is not very informative, it needs some context. Let's do this by enhancing exhibit 1 using a non-numeric variable as follows:
1. Place the cursor in the table and proceed to Table --> Insert --> Insert Row Above (Right click also gets you there.)
2. Insert 1 row above.
3. In the cell above Revenue type @P20X1. The@" flags this as a non-numeric variable.
4. Proceed to Edit --> Update --> Non-numeric Variables.
5. Update the value to 2023 using data entry or by navigating to the Non-numeric Data tab (shown above) and updating the value there.
The report specification and output are shown in exhibit 2 below:
Exhibit 5 - Dynamic Variables - Design
|
||
@P20X1
|
||
Revenue
|
[REVENUE]
|
|
Exhibit 5 - Dynamic Variables - Output
|
||
2023
|
||
Revenue
|
1,000
|
|
TIP: Non numeric variables can appear as part of sentences anywhere in the document. For example, "The @Speed @Colour brown fox jumped over the lazy @Animal" will resolve to values given to the named variables "Speed", "Colour" and "Animal".
2. GETTING STARTED
|
The report author is free to define numeric and non-numeric variables that do not get tagged such as the context for the reporting period P20X1 in exhibit 5 above. Another use case for numeric user defined variables, in particular, is where an analysis is required at a granular level beyond the scope of the taxonomy or the reporting standard. Taxonomy authors tend to be a bit pedantic about what gets included in a taxonomy and very often items such as obvious sub-totals or commonly made voluntary disclosures are omitted.
Untagged user defined numeric variables must be added manually in the Numeric data tab because they need to be associated with a dataset period. When referring to a user defined (untagged) variable in the document the dataset periodRef should be included in brackets as a suffix or the periodRef defaults to 1.
In the exhibit below a mixture of tagged numeric variables, untagged user defined numeric variables and non-numeric variables can be seen. Note how only the user defined numeric variables are qualified with period references:
Exhibit 6 - User Defined Variables - Design
|
Decimals refers to how accurate a number is to a specified number of decimal places ("decimals"). Scale refers to how a number has been transformed to make it easier to read in an iXBRL report e.g presented as thousands, millions, etc. Decimals and scale attributes are set globally for a dataset but can be overridden on an individual numeric item basis.
Writer always captures the actual number and then transforms it for display purposes based on the following formula DisplayValue = Round(Value, Decimals) / (Scale ^ 10). To display 1,234,567.23 in round thousands then its decimal precision will be -3 and scale factor 3. To get increasing levels of precision in the displayed amount add 1 to the decimals attribute. The number of decimals to display for the precision required is equal to the sum of scale plus decimals.
To get back to the original number multiply the number displayed by 10 ^ scale. There will be a loss in accuracy depending only on the decimal precision. The exhibit below clearly illustrates this:
Exhibit 7
|
2. GETTING STARTED
|
In the following example some report authors would be happy enough with the values for Cost of Sales being shown as a positive number, many more would prefer to see brackets around the number as it makes the financial statement more readable. The display sign in a report can be reversed by right clicking on a tagged item and selecting"Reverse Display Sign" from the pop-up menu. Doing this has no impact on the data point values which are identical for the two periods in the exhibit. This is just cosmetic.
Cost of Sales for period 2 is displayed as a positive value by default because its XBRL balance attribute is debit and its value is a debit balance. Period 1 has surrounding brackets as its display sign has been reversed.
Exhibit 8 - Reverse Display Sign - Design
|
||||
@P20X1
|
@P20X2
|
|||
Revenue
|
#A0010
|
#A0010
|
||
Cost of sales
|
#A0020
|
#A0020
|
||
Gross profit
|
#A0020
|
#A0020
|
||
Exhibit 8 - Reverse Display Sign - Output
|
||||
2023
|
2022
|
|||
Revenue
|
1,000
|
1,000
|
||
Cost of sales
|
(800)
|
800
|
||
Gross profit
|
200
|
200
|
||
Please note that reverse display sign does not apply to user defined values, they are always displayed based on their value.
2. GETTING STARTED
|
An entity could use their own chart of account codes as identifiers for numeric items especially in respect of those in the primary financial statements of a set of accounts. Detailed notes and disaggregations could pose difficulties in mapping.
It is probably best to generate numeric codes using the numeric code generator and map your GL codes onto these codes at a later stage in the reporting life cycle rather than using your own codes up front. This will facilitate reuse of a report design across different entities, reduce complexity and also facilitates collaboration.
The code generator produces a unique code for numeric items which have been represented by a dash character "-" in a tagged table cell. The codes are computed based on the items name, the taxonomy it belongs to and any dimensional qualifications applied. Codes generated are prefixed by a "C" for credit balance, "D" for debit balance or "N" for no balance attribute specified by the taxonomy. The steps to generate codes are as follows:
1. Before Tag On is pressed enter '-' as the value for the numeric item in the cell.
2. Tag On.
3. Proceed to Edit --> Generate NumericCodes
The financial statement used above will appear as follows:
Exhibit 9 - Auto Generated Codes - Design before
|
||||
@P20X1
|
@P20X2
|
|||
Revenue
|
-
|
-
|
||
Cost of sales
|
-
|
-
|
||
Gross profit
|
-
|
-
|
||
Example 9 - Auto Generated Codes - Design after
|
||||
@P20X1
|
@P20X2
|
|||
Revenue
|
#C111E5942
|
#C111E5942
|
||
Cost of sales
|
#D586E9627
|
#D586E9627
|
||
Gross profit
|
#CFD94DD7A
|
#CFD94DD7A
|
||
2. GETTING STARTED
|
In the exhibit below expressions are used for non-numeric items to compute values during processing. This feature has been implemented to access report information in respect of datasets.
Exhibit 10. - Non-numeric Expressions
|
||
Design
|
Expression
|
Output
|
@Currency
|
=Currency(1)
|
EUR
|
@DateBegin
|
=DateBegin(1)
|
01/01/2023
|
@DateEnd
|
=DateEnd(1)
|
31/12/2023
|
@DateYear
|
=DateYear(1)
|
2023
|
2. GETTING STARTED
|
Relationships enable the representation of straightforward connections between numeric items using their corresponding codes. These relationships are used to calculate formulae for manual data entry and input spreadsheets (Please note that the formulae are applied when capturing the data and not at the time when the data is processed.)
The implementation is kept deliberately very simple to reduce the risk of unintentionally introducing errors into an otherwise perfect dataset because new values are being computed on data capture. Some practitioners would argue that data entered should already include aggregations and no computations should be performed. Nevertheless, this feature is too useful to be omitted and is especially useful in closed reporting.
The rules for relationship expressions can be summarised as follows:
1. Expressions are between numeric variables as identified by their codes.
2. Expressions are of the form Code1 = Code2 + Code3 - Code4.
3. Only parentheses after a code are understood e.g. Code(+) or Code(-) indicating an offset for period.
4. The offset for (+) refers to the periodRef of Code1 + 1.
5. If the offset is (-) then the periodRef is the periodRef of Code1 - 1.
6. A dataset with a referenced periodRef must exist or an error will occur.
7. Relationships for monetary items with credit and debit balances would generally only use the "+" operand.
8. The relationship Code1 = -Code2 is expressed as Code1 = 0 - Code2.
As an example, for simplicity, assume there are two user defined numeric variables with identifiers U0010 and U0020 representing profit for the period and revenue reserves. Profit is added to reserves at the beginning of the period to yield reserves at the end of the period.
The foregoing yields the expression U0020 = U0020(+) + U0010.
In the exhibit below the movement in reserves is examined over two periods:
Exhibit 11 - Relationships
|
|||
20X1
|
20X2
|
||
Reserves at beginning of period
|
(11,000)
|
(10,000)
|
|
Profit for the period
|
(2,000)
|
(1,000)
|
|
Reserves at end of period
|
(13,000)
|
(11,000)
|
|
2. GETTING STARTED
|
Numerical Relationships (Continued)
Below is a snipped of the _data entry form. Note that the values are entered as negative (credit) values. The yellow cells are computed based on the relationship between reserves and profits. The form is also filtered on category Reserves.
Exhibit 12
|
To facilitate the building of relationships a range of cells can be selected on the document and pasted into the relationships builder. Just right click having selected the cells and select "Copy Code(s)". Depending on the way the elements are laid out in the document the target of the relationship (e.g. U0010 above) may be at the end of the list. The operation is assumed to be addition but this can be changed in the editor.
In the Relationships tab, "Parse" can be chosen to help validate the relationship expression(s) by providing a more readable version using the numeric item descriptions instead of codes.
3. FORMATTING
|
The XBRL standard provides comprehensive guidance on how data displayed in iXBRL reports can be transformed into actual numbers or dates suitable for consumption by software. Digital-first means that Writer works the other way by taking actual data and transforming it for display by reference to the XBRL rules.
Writer captures data in its native un-transformed state for display as follows:
1. Text as is, no change.2. Numeric values in the form nnnnnn.nn.
3. All dates and derivatives of dates in the form YYYY-DD-MM.
4. Percentages as their actual decimal value.
5. Boolean True/False values as true or false. (NB. Case insensitive).
A derivative of a date is something like a YearMonth or a MonthDay, these are datatypes in their own right and their values can be derived from dates. To keep things simple Writer always insists on using the YYYY-MM-DD format. So, 2023-10-15 as a YearMonth is 2023-10 or as a MonthDay is 10-15.
By navigating to File -> Properties and opening the dialog the default display properties for numbers can be set.
Numbers can be formatted as num-dot-decimal or num-comma-decimal depending on whether the fractional separator is a decimal point or a comma e.g. in num.dot.decimal the fractional separator is a decimal dot. The thousands separator is based on the system separator but cannot be the same as the fractional separator.
Support for xt:num-dot-decimal-apos and ixt:num-comma-decimal-apos format codes will be provided for in a future release of the software. There are currently no plans to support the ixt:num-unit-decimal or ixt:num-unit-decimal-apos format codes.
Consideration will be given to explicit selection/override of the system thousands separator in a future release of the software.
The number format cannot be overridden for individual numeric items.
Data transformations for dates are initially driven by the order in which year, month and day are displayed. This can be set in the File --> Properties dialog by selecting a date format of date-day-month-year or date-month-day-year or date-year-month-day. Date-year-month-day is the order assumed in the discussion and examples below.
The display of a date can be transformed by placing a flag in brackets after the value or the definition of the report variable on the face of the document e.g. YYYY-MM-DD(FLAG). The flags are:
1. D: year-month-day (date type).
2. A: year-monthname-day (date type).
3. T: year-month (YearMonth type).
5. E: year-monthname (YearMonth type).
4. S: month-day (MonthDay type).
year-month-day and year-monthname-day are by far the commonest formats for dates. The derived values are not often used.
The separator used for dates and word used to describe the month of the year is based on the system locale so it is possible that output from one machine may differ from another. Using the precise format codes for dates set out in the XBRL Transformation Rules Registry is under review and may feature in a future release of the software. In this release the format codes are computed automatically based on the locale.
In the example below the display value for 2024-12-31 entered by way of static text and also as a non-numeric variable as modified by display flags are shown:
Design
Description
|
Date
|
|
D: year-month-day
|
2024-12-31(D)
|
|
A: year-monthname-day
|
2024-12-31(A)
|
|
T: year-month
|
2024-12-31(T)
|
|
E: year-monthname
|
@MYDATE(E)
|
|
S: month-day
|
@MYDATE(S)
|
Output
Description
|
day-month-year
|
month-day-year
|
year-month-day
|
Date(D)
|
2024-12-31
|
12/31/2024
|
2024/12/31
|
Date(A)
|
2024-12-31
|
December 31 2024
|
2024/12/31 (note)
|
Date(T)
|
2024-12-31
|
12/2024
|
2024/12
|
Date(E)
|
2024-12-31
|
December 2024
|
2024 December
|
Date(S)
|
2024-12-31
|
31/12
|
12/31
|
notes:
The report writer uses the computer's system date separator.
There is no general transformation rule for year-monthname-day so the value is not transformed.
Always ensure that the data type of the fact is appropriate when using date formatting. If the output from the above example is run through an XBRL validator it will report that 2014-12 is not a valid value for two items. This is correct because the facts data type is date and not YearMonth.There is no element with a YearMonth data type in the taxonomy to use as an example so we cheated but got caught out by the XBRL validator.
TIP: Always validate report output using an appropriate XBRL validation tool (See Assurance).
The system recognises tagged percentage items from their data type which is defined in the taxonomy. When a numeric item representing a percentage value is added its attribute value for decimals is set to to 4 and the attribute value for scale to -2. These values can be overridden on an individual numeric item basis.
Percentages in Writer are captured at their actual value e.g. a display value of 20.55% would have been entered as a decimal number of 0.2055.
Static values entered on the face of the document are treated the same way as for dynamic numeric items but the attribute values for decimals and scale are fixed and cannot be overridden.
When an item is scaled for display it is first rounded to the decimal digits and then divided by 10 to the power of scale. 10 to the power of -2 is 0.01, and 0.2055 divided by 0.01 is 20.55.
In the exhibit below the decimal precision of the dynamic variable has been overridden and set to 2. The value displayedis 21. The static value is displayed using the default values for decimals and scale attributes which results in a display value of 20.55.
Exhibit 13. - Formatting Percentages - Design
|
|||
Depreciation rate, property, plant and equipment (%)
|
20.55
|
#NA4E168F4
|
|
Exhibit 13. - Formatting Percentages - Output
|
|||
Depreciation rate, property, plant and equipment (%)
|
20.55
|
-
|
|
Only tagged items can be recognised as boolean item types based on their definition in the taxonomy. If entering a value on the face of the document then 'True' and 'False' are the only valid values for tagged items that can can be used, anything else will be treated as false by default. However, using a non-numeric variable one can enter a sentence with a suffix of either (T) or (F) e.g. 'This is a true statement(T)'. Without the parameter the value will be interpreted as false. 'True' and 'False can also be used as values for the variable in which case the flag is unnecessary.
Elements with an item type of Boolean are unusual in financial reporting but quite common in sustainability reporting. The IFRS_AT_FULL_2023 taxonomy does not have any boolean items.
The following format codes are used internally by the software:
1. ixt:fixed-false: Used when displaying text representing a boolean value.
2. ixt:fixed-true: Used when displaying displaying text representing a boolean value.
3. ixt:fixed-zero: Used when displaying a dash for a zero value (see note).
4. ixt:fixed-empty: Used when displaying an item that has no content.
Currently the software only permits a dash ('-') as an alternate value for 0 (Zero). XBRL allows for any text but for digital-first reporting this is unnecessary.
ixt:fixed-empty is used to flag items. An example would be a piece of text denoting a director approved the accounts. The words "Approved by Director" are not significant in themselves but if the value is tagged and qualified to specify that, say, Director1 approved the report and that director has been identified elsewhere then the text has significance.
4. DATA
|
When we talk about data in ABRL we are principally talking about values for records in the internal numeric items and non-numeric items data tables that can be imported or entered manually. The identity of these records is determined by the report design; however, their values are not. Numeric and non-numeric records represent dynamic data.
A report requires at least one currency and one reporting period and there is actually no requirement to have any numeric or non-numeric records. Such a report represents purely static data stored in the document. A typical report design contains a mixture of static and dynamic data.
Tags are meta-data, data about data, describing the characteristics of document items in XBRL terms. Tag data cannot be imported or exported on its own, it is intrinsic to the report design.
Writer supports three formats for data import and export of dynamic numeric and non-numeric data:
1. Input Spreadsheets
2. XML Exchange
3. CSV for numeric data
An input spreadsheet contains updatable details for reporting periods, numeric records and non-numeric records. After update in a spreadsheet these values can be imported into the report. (See chapter on integrations below).
The input spreadsheet is intended to be the primary vehicle for exchanging report data with the outside world. Exchange is a two way process including both import and export of data.
This data is not really useful to the typical report author, it is geared to software developers. The xml exchange format is a simple representation of the internal report data in the extended markup language ("XML"). XML is widely used to quickly exchange data between and within software applications. This format is used extensively behind the scenes by Writer.
XML data exchange files written by other software in accordance with the ABRL Schema for xml data exchange can be imported by Writer. In this way the xml exchange format can provide a bridge between back-end systems and ABRL Writer or other ABRL software such as the ABRL Report Server. Exchange files facilitate the automation of report production.
The comma separated variable ("CSV") format is supported natively by Excel and many other applications. Only numeric data records can be exported and re-imported in this format.
One might think that importing XBRL or iXBRL would be a feature that is available out of the box by default but this functionality poses a number of challenges. Consider this, report data represents records for numeric and non-numeric items in respect of disclosures set out in the report document. Importing XBRL or iXBRL would only work reliably for closed reports where the data-points are known and fixed in advance. In a report authoring tool that caters for open reports this feature might create false expectations and potentially result in errors and omissions.
The direct import of XBRL and iXBRL is not supported in Writer. Our preferred approach is to provide ABRL Exchange, a separate utility to update xml exchange files from XBRL and iXBRL reports. Data points included in the source data and not in the target exchange file can be easily identified and logged for investigation. The data in the updated exchange file can then be imported into Writer.
The ABRL Exchange utility is not currently available.
5. ADVANCED
|
Items appearing in top level business reports are usually aggregations of many sub-items such as general ledger accounts as in the case of financial accounts. Breaking down an item into its component parts for reporting purposes is referred to as disaggregation. Sometimes this is done by including the individual elements making up a balance in the taxonomy, another approach is to analyse an item by its identifiable characteristics. In XBRL the latter is achievedby qualifying an already tagged item using additional dimensional characteristics.
The two classic examples for qualifying items dimensionally are Plant and Machinery and Equity. These are good candidates because both use a classification system to characterise their components e.g. Land and buildings, Machinery, Vehicles, etc.
In order to discover the dimensional characteristics for Plant and Machinery follow these steps:-
1. Locate Plant and Machinery in the Taxonomy.
2. Select the Plant and Machinery element.
3. The "Inspect Characteristics" button should be enabled. Click it.
4. A Dimensional Characteristics dialog opens.
5. Discover that Plant and Machinery is only associated as a line item with one table.
6. Discover that there are three dimensions used to describe Plant and Machinery.
7. Discover that each dimension has a number of member values.
8. Discover that each dimension has a default value.
Below is an example of the dialog for selecting dimensional characteristics:
Exhibit 14
|
5. ADVANCED
|
The review characteristics process allows discovery of dimensional characteristics. To actually apply qualifications to an item do as follows:
1. Select an item that has already been tagged in the document.
2. Locate that item in the taxonomy by right clicking and using the Locate option.
3. Is the "Inspect Characteristics" button enabled?
4. If so, then right click on the item and select "Characteristics".
5. The Dimensional Characteristics dialog appears but is in active and not inspection mode.
6. Select the table characterising the element and select the desired dimension member values.
7. Apply the selected characteristics to the tag.
8. To check the now qualified document item go to the Tag Info tab.
9. Click on the cell just qualified and the Tag Info tag should reflect the selected characteristics.
In the example output below the breakdown of the carrying value of plant and machinery is shown as between the gross carrying amount and accumulated depreciation. The following should be noted:
1. The same element was used three times: PropertyPlantAndEquipment.
2. Gross carrying amount and accumulated depreciation are qualifications of PropertyPlantAndEquipment.
3. The default value was used for the "Classes of property, plant and equipment [axis]".
4. The default value was used for the "Property, plant and equipment by operating lease status [axis]".
5. Accumulated depreciation will not need to have its sign reversed to display properly.
Example 15 - Advanced Tagging
|
||||
Plant and machinery
|
||||
2023
|
2022
|
|||
Gross carrying amount
|
2,000
|
2,000
|
||
Less: Accumulated depreciation
|
(1,000)
|
(1,000)
|
||
Carrying amount
|
1,000
|
1,000
|
||
5. ADVANCED
|
Numeric items that do not represent monetary items or share types but reference a tag have a unit type of "pure" assigned by default. XBRL provides a unit types registry where standard units for different properties such as weightarea, etc. are defined. The default value of pure can be overridden for theses numeric data items based on their itemType. For example, an element named ProductWeight could be defined as having a massItemType which could be measured in grammes, kilogrammes or tonnes.
The unit associated with a numeric item representing a monetary amount cannot be overridden. User defined numeric items that do not have a tag reference cannot be associated with a unit other than pure as the itemType is a pure number by definition.
There are not many opportunities in the IFRS_AT Taxonomy to override a tagged items itemType. The element AreaOfLandUsedForAgriculture has a data type of areaItemType. To get to choose an appropriate measure take the following steps:
1. Add a table to the document and select a cell and place a dash ("-") in it.
2. Find the element "Area of land used for agriculture" in the taxonomy and tag it.
3. Generate a numeric code for the item.
4. Locate the code in the Numeric Data tab.
5. Navigate to the property inspector and open the dialog below from Overrides --> Units.
The choice of measures will appear as below:
Exhibit 16
|
5. ADVANCED
|
Images can be inserted into the document either as part of the body of the document or in table cells. An image inserted into the body of the document will initially be inserted at its actual size and can be scaled after insertion by clicking it and dragging its scaling handles. We recommend that these images are initially sized so they do not need to be significantly scaled for display.
Images inserted into table cells can be stretched or tiled by setting cell properties. We recommend inserting cell based images in table cells via the table cells property functionality of the Table and Cell Formatting dialog.
Writer is not intended as a replacement for advanced XHTML authoring tools such as Adobe Dreamweaver typically used in the publication of "Glossy Reports". Writer's image handling capability is fairly basic.
The following are the steps to insert an image in a table cell:
1. Insert a table into the body of the document and select a cell.
2. Right click on the selected table cell and select Table and Cell formatting.
3. Select the Cells tab in the dialog and press Picture.
4. Open an image file and set its position.
In the example below a screen shot of this document being edited is displayed. It is inserted in row 2 of a 2 X 1 table.
Exhibit 17
|
TIP: Images are stored in the report specification and need to be reloaded if modified externally.
5. ADVANCED
|
XBRL defines a textBlockItemType which is a data type that has mixed content which can include a simple string, or a fragment of XHTML or a mixture of both. So, for example, data could include text followed by one or more tables of data interspersed with text and images. Elements defined with the “textBlockItemType” are used for marking up larger pieces of information contained in business reports such as explanatory notes and accounting policies or assumptions. Those elements are of different granularity and may not require detailed tagging. A textBlock tag acts like a bucket for data. A textBlock can also contain tagged elements.
The simplest approach to textBlocks consists of surrounding whole sections of the document with a tag. This tag could contain other textBlock tags. This pattern can be visualised as follows:
.----Open outer tag
.--------Begin inner tag#1
.-----------Table1 with tagged cells
.-----------Some narrative
.--------Close inner tag#1
.--------Begin inner tag#2
.-----------Some narrative
.-----------Table with tagged Cells and images
.-----------Table with tagged Cells and more textBlocks
.--------Close inner tag#2
.----Close outer tag
A pattern not unlike the foregoing can be found in the IFRS SDS Sustainability taxonomy. This pattern allows grouping of related data and provides an opportunity for analysing software to make complex narrative easier to follow andunderstand.
In the example below an accounting policy for inventory is inserted as body text in the document i.e. not in a cell. The text is enclosed in tags which are visible in the report specification design but not in the iXBRL. Thus text blocks provide the only exception to rule#1 that says that only table cells can be tagged.
A text block tagged section can be added to the document using the following steps:
1. Select a fact with textBlockItemType in the taxonomy representing an accounting policy.
2. Right click on the item.
3. Copy the id attribute using the option in the pop-up menu.
4. Navigate to "Insert --> Begin Text Block" in the document Insert menu and click.
5. Navigate to "Insert --> End Text Block" in the document Insert menu and click.
6. Insert the text of the accounting policy between the opening and closing tags.
Example 8 - Text Block Tags - Design
|
Example 8 - Text Block Tags - Output
|
Inventory
Inventories are stated at the lower of cost and estimated selling price less costs to complete and sell. The cost of inventories is determined using the first-in, first-out (FIFO) method.
5. ADVANCED
|
A nested table is a table inserted in a table cell. Writer supports the insertion of a table in a cell and the tagging of cells in the nested table. iXBRL allows non-Numeric elements to have child nodes which is consistent with supporting nested tables. textBlockItemTypes can be used to implement the nesting of tables that contain tagged cells.
In order to implement this in practice follow these steps:
1. Insert a table as usual.
2. Select the cell that will be tagged with a textBlockItemType.
3. Place some text in the cell and tag it with the selected textBlockItemType.
4. insert a table in the same cell after the text.
5. Put values in the cells of the inserted tables.
6. Individual cells in the embedded table can now be tagged separately.
7. We haven't tried it but there is no reason why a cell in the nested table cannot contain another nested table.
The foregoing can become very complex, hard to review and is potentially error prone. Please, as a rule, only use non-numeric textBlockItemTypes as the parent of the nested table and please give it a value. If it is not practical to assign a value then use a text block tag as described above.
It is possible to do "very creative" things with this feature which is why we would discourage its use.
5. ADVANCED
|
A duplicate is recognised when a document item is tagged referencing an element in the taxonomy with the same name, period reference and/or dimensional qualifications as a previously tagged element. The value of the item and the decimal precision or scale of numeric items is not considered by Writer. The steps used internally to evaluate a new tagged item are as follows:
1. When a new document item is tagged at design time its details are added to an internal table of tags.
2. If the same item is subsequently qualified, then this information is also stored in the same tag record.
3. Another item tagged with the same identity and/or qualifications is subsequently added to the list of tags.
4. When the report specification is being processed and contains two or more tags that are identical, only the value for the first tag is included as data, the second and subsequent items in the report output are redirected to use the data captured from the first tagging.
If the value of the second and subsequent tagged duplicate items are the same as the first, then the items are said to be complete duplicates and if numeric items are referred to as consistent duplicates. If the values are different then the duplicates are said to be inconsistent duplicates. The software does not permit inconsistent duplicates.
There may be the odd occasion where the same numeric item is displayed using a different precision or scale in the same report. It may be necessary in these cases to create a user defined (untagged) variable to hold the value for display.
5. ADVANCED
|
Typed dimensions member values are not pre-defined taxonomy elements but are user defined data. The report author must provide a values for a typed dimension when setting an items characteristics. The word "typed" refers to the data type of the value required e.g. string, number, etc. Typed dimensions typically are used for unique identifiers e.g. Legal Entity Identifiers.
Typed dimensions are not common and their use is not generally encouraged. Writer does support typed dimensions but if there are large number of records to be tagged the work can become quite tedious. It is best to use static text entered on the face of the document to represent data that will be characterized by a typed dimension.
One type of data represented by typed dimensions is the record type. A record is a collection of data associated with a unique identifier. A list providing details of subsidiaries, their identifiers, name, country of incorporation is an example of a list of records. This type of data changes only slowly over time so after the initial set-up cost of tagging this data maintenance should not be too arduous.
An enumeration refers to a list of one or more allowed pre-defined values for a specific data element. The list of possible values for an item that has extensible enumeration as its type can be obtained by clicking on the button next to the data type field in the details section at the bottom of the taxonomy tab.
There are no extensible enumerations in the IFRS 2023 accounting taxonomy but they do feature regularly in taxonomies covering sustainability reporting.
The values for enumerated items are quite ugly in appearance by design in order to facilitate consumption by software. To circumvent the ugly display a hidden font can be used for the tagged value and a friendly dynamic text value can be used for display purposes. Just be warned that hiding tagged values from display is generally frowned upon and may resultin rejected submissions by regulators.
6. INTEGRATIONS
|
Writer currently integrates with Microsoft Excel. Integration is built around the Input Spreadsheet and offers passive and active spreadsheet modes. We plan to extend this integration to accounting platforms but this will be centered around those platforms integration with Excel.
Passive Input Spreadsheet
A passive input spreadsheet is a .xlsx file that contains no macros and is considered safe to upload and download from the cloud and is safe for exchanging data with others.
Active Input Spreadsheet
An active input spreadsheet is a .xlsm file that contains macros. The code is exposed so it can be reviewed and its safety determined independently. Active input spreadsheets contain embedded iXBRL templates which are filled by the data entered when the macro code is run. Active input spreadsheets are stand alone applications that produce iXBRL reports. They are particularly useful in closed reporting scenarios.
Functionality
Input spreadsheets offer the following functionality:
1. Basic Input Spreadsheet.
2. Input Spreadsheet Form.
3. Mapped Input Spreadsheet.
The basic input spreadsheet is easily understood without little explanation. The process is as follows:
1. Export the input spreadsheet by navigating to Integrations -> Input Spreadsheet.
2. Read the instructions carefully.
3. Update report start dates and end dates in the Datasets sheet.
4. Update numeric values in the NumericData sheet.
5. Update non-numeric values in the NonNumericData sheet.
6. Save the workbook and import the workbook into the report.
Input forms contain a sheet called "InputForm". Here a "smart" rendering of the report is provided. The presentation will not be perfect but it is usually acceptable because Writer is so table driven.
In an input form cells shaded blue are for data entry. Cells shaded cream contain formulas linking to other blue shaded cells from which they will pull their value. other cells are read only and cannot be changed.
It is important to note that not all numeric data and non-numeric data will necessarily be captured by the form so the NumericData and NonNumeric data sheets should be reviewed for data entry (blue) cells. The other cells (cream) should be populated with values entered into the form.
The password for sheets is "xbrl". In the event that all data can be captured on the input form the other sheets can be hidden and the instructions sheet modified. Be careful modifying the data entry sheets as the workbook could easily be rendered useless. At least it is easy to regenerate!
A mapped input spreadsheet allows the user to import data from the general ledger or other external data source into a report. This is very powerful, even awesome, but effort is required by the user to prepare the data file for input.
Data is usually fairly accessible with many systems exporting trial balances or other system data to Excel. The mapping of general ledger codes, in the case of accounting data, to report identifiers will have to be provided by the user. Some skill with Excel is required to assign pre-built mappings to a data export in an automated fashion. Some systems facilitate the storage of external mapping codes which avoids the assignment of mappings step. In some scenarios using report identifiers that are the same as system codes will result in a 1 to 1 mapping and makes life very easy.
The process can be simulated for a 1 to 1 mapping report as follows:
1. Assume that external codes are the same as report identifiers.
2. Navigate to Data --> Chart of Accounts and generate the temporary workbook.
3. Go to the 121 Mappings sheet and enter in random test values for at least the first two rows. Save this sheet as a CSV file.
4. Navigate to Integrations --> Mapped Input Spreadsheet and import the CSV file just generated when prompted.
5. Open the workbook generated and confirm that values on the NumericData sheet correspond to the values on the Mapped data sheet.
6. Note that the Target Code on the Mapped Data sheet is editable. Copy the code for the first item to the second and see how the values change. The second item should now have a value of 0 in NumericData.
7. The numbers in the two editable datasets can be changed. Confirm that values in the NumericData sheet update correctly based on the mappings.
8. Review the NumericData sheet for editable (blue) cells.
9. Update NonNumericData.
10. Save changes and import the workbook into the report.
7. ASSURANCE
|
It is critical that the report author can assure themselves that report disclosures and data are accurate, reliable, and compliant with regulatory standards and the XBRL standard.
The first step in the assurance process is to review the document design in detail. Disclosures can be related directly to the taxonomy by making sure the taxonomy tab is active and right clicking on tagged items and selecting the option to "Locate". Where an item has been qualified dimensionally this will be indicated in the status bar when the item is clicked. The dimensional qualification details can be seen by selecting the "Tag Detail" tab and clicking on the cell again.
It is worth remembering that taxonomies are authoritative documents prepared by subject matter experts and thus provide excellent guidance on report disclosures. Very often references are provided to underlying reporting standards.
We discuss below additional aspects of assurance which help with ensuring completeness and accuracy of data:
1. Sanity checking.
2. Internal data.
3. Tag mapping.
4. Report processing log.
5. Third party software validation.
The sanity check is focused on how tidy the report design is e.g. identifying unused items and enumerating items that may need attention. The check may also highlight potential errors in the naming of numeric and non-numeric variables. For example, email addresses should not be entered as static text:tom [gmail].com will result in as a non-numeric variable with identifier "gmail". Similarly static text that includes the hash#) character should be captured in a non-numeric variable. The sanity check option can be found on the main menu under Assurance --> Sanity Check.
The internal data report is an Excel workbook that provides the details of the data contained in the datasets, numeric, non-numeric and tag data tables. This allows for a detailed audit of the report data and meta-data. Independent reviewers and auditors would find this indispensable in providing assurance as to the accuracy of data entered or imported from an external source.
It should be noted that when a tagged item is selected in Writer the status bar provides information about the tag reference which can be used to lookup the details in the workbook. Similarly a numeric variable code can be used to lookup the NumericData sheet where that tag reference can also be found and cross-referenced.
This report provides an in-depth review of tagged data in the report. It works by processing the report replacing data point values with a link to tag information appended to the bottom of the report. This exposes the tag information related to each tagged item in the report output and provides assurance that the report output tagging is complete and accurate. It is easy to spot items that have not been tagged. This report can also be very useful in an independent review.
The example below is a good illustration of where line items are not tagged and where user defined variables had to be used where there were no referable concepts in the taxonomy:
7. ASSURANCE
|
Exhibit 18
|
The report processing log is one of the files output on processing a report. It is vital that this log is examined before publishing a report as it could contain vital clues in respect of actual or potential errors. The processor does checking based on the existence of elements, data type validity and validity of dimensional qualifications. The validation is not a replacement for validation by an XBRL processor but is very useful nonetheless.
When you are happy that your report output is complete and accurate it is time for the acid test: validation by third party XBRL processing software. Arelle is an open source XBRL processor that is commonly used for this purpose. It can be downloaded from https://www.arelle.org.
There are two validation scenarios. The first is where you just want to validate the file against its taxonomy, Arelle does this out of the box by default. There is a second scenario where the report may be subject to separate "filing" rules. Arelle includes disclosure system checks for many authorities. In the absence of such checks some authorities provide portals where test submissions can be made.
Arelle is an excellent validation tool. It can be frustrating, however, where Arelle validates in the first and even the second scenarios above but a regulator's submission gateway still rejects a file. In these (not uncommon) circumstances expert help may be required.
If Arelle is installed Writer can be configured to process a report and submit it to Arelle from within the application.
At this stage you are now at the point where a report can be printed out and a good old fashioned read of the text and manual re-cast of the numbers performed.
A paper based approach to digital reporting would actually start at this point which does not seem logical if you think about it? Kind of like putting the cart before the horse!
8. MISCELLANEOUS
|
Filing rules are sent to test our patience. These are rules that are applied by competent authorities outside of rules that a taxonomy might contain. Writer is not specifically designed to comply with filing rules unique to any one competent authority or regulator and is principally designed to produce iXBRL compliant reports.
Fortunately, filing rules are public and there is a filing rules module within Writer that caters for rules that are outside the control of the report author. A good example of this is where a taxonomy implements a design pattern that the competent authority does not like and insists on being overridden. Unless independent XBRL validation software knows about such filing rule deviations it will pass a file that the regulator will later reject. This is unfortunate and very confusing but it is a reality. Luckily it is a rare occurrence,
Many filing rules are within the purview of the report author. A common example would be that there should be no hidden tagged cells. Another is that there should be no inconsistent duplicates. The former is under the control of the author, the latter is enforced by Writer by design. If a report is to be filed with a competent authority then it is best to familiarize yourself with published guidance and rules.
Even if you are not required to file with a competent authority it is not a bad idea to refer to the filing rules if other entities in your jurisdiction are required to file to a rule book or style guide.
Please note that the Writer filing rules module is updated incrementally as new rules or taxonomies are encountered. These updates are released as patch releases and not part of the formal release cycle.
It is possible to import documents from MS Word or similar open source word processors by first saving them in the .rtf (Rich Text Format) and then importing them using the options under the Tools menu. In our experience this may be more trouble that it is worth. documents, in general, tend not to be particularly well structured and, in particular, do not always use tables as containers for numbers. However, if your document is well structured i.e. a tabular report then it may be worth a try.
Interestingly, MS Word does not support export the .xhtml format which is a more rigorous format than the .html format that it does support.
Importing .pdf (Portable Document Format) documents into MS Word and then exporting to .rtf is a disaster, completely unreliable. Don't waste your time trying this.
A document can only be imported or inserted into a report that has already been created and associated with a taxonomy.
Most taxonomies are updated periodically. In 2023 many of the important taxonomies are being updated annually. This reflects the rapid development of reporting standards including changes being wrought by sustainability reporting. In time, it would not be surprising if taxonomy update cycles extended to longer intervals of three years or more.
A taxonomy is updated to reflect actual changes in reporting standards or evolutions of interpretations of standards as practical use of the standard proceeds. A good example of the latter would be IFRS 15 - Revenue from Contracts with Customers. When a taxonomy is updated it should be downloaded packaged for use with Writer from the ABRL Website. A report specification authored on an earlier version of a taxonomy can be updated using TOOLS --> Update Taxonomy.
Please note that if you are a filer just make sure that the competent authority you are reporting to accepts the latest version of the taxonomy before you commit to any work. Financial reporting and sustainability reporting standards and taxonomies are published by bodies that are independent of regulators who sometimes are playing a game of catch-up. Usually this lag in implementation is recognised in local adoption legislation.
It is also worth noting that taxonomies tend not to change because of changes in the XBRL standard. The XBRL standard is very stable and a huge amount of effort has been invested in making it very robust. The technology continues to evolve but enhancements are, for want of a better description, mostly cosmetic: they do not affect the core but help make implementing the technology easier.
It is important to understand the fundamental difference between validation of output by an XBRL processor with the validation performed by Writer. An XBRL processor validates the report after it has been produced whereas Writer validates the report as it is being produced.
Writer is primarily focused on the following:
1. The existence of tagged report items in the taxonomy.
2. The value assigned to a tagged item is consistent with an items base type.
3. The existence of dimension members.
4. Identifying duplicates.
By its nature the validation performed by Writer is limited which is why validation with an independent 3rd party processor such as Arelle is recommended. The XBRL processor will perform a comprehensive check in accordance with the XBRL standard and by reference to the taxonomy. The taxonomy may contain calculation relationships and other validation rules that will be applied on reported on.
There is one issue that arises with XBRL validation and that is that error messages are very verbose and can be very hard to understand. For example when validating a draft of this document the the message below was received. It's an absolute classic: verbose, technical and virtually incomprehensible to the untrained eye. This message is actually telling us that there are two or more bookmarks in the document with the same name "Taxonomies".
Exhibit 19
|
TIP: Validate documents as they are being built.
TIP: Seek expert advice before wasting too much time over very technical errors.
©Copyright Active Business Reporting Ltd 2007 - 2025.
This document was generated using a trial version of the ABRL Writer software.