How can I go back to an old version of the XBRL Auditor after installing an update?

When updating the XBRL Auditor, the old version will always be preserved. For instance, if updating from version 1.2.6 to 1.2.7, the version 1.2.6 is still installed. It can be started manually, by running the AMANA.XBRL.Auditor.exe in the users local AppData folder, which can usually be found here:

C:\Users\user.name\AppData\Local\XbrlAuditor\app-1.2.6\AMANA.XBRL.Auditor.exe

The taxonomy is available only in English, or the Formula validation results are displayed as cryptical messages. How do I update/repair the Taxonomy Cache?

It seems that the XBRL taxonomy cache is incomplete. To solve this issue, please execute the following steps:

Open the Auditor and go to Settings -> XBRL Processor Settings.
Make sure, that Force XBRL Offline cache is checked (if not, please check & save).
Open the XBRL Cache Folder.
Extract the following ZIP file in this folder, replace existing files if asked.
https://downloads.amana-consulting.de/xbrl/tagger/Cache/XBRLCache.zip
Delete the #bin folder.
Restart the Auditor.

How can I validate an XHTML report without tagging?

Non-XBRL reports can be validated with the integrated XML Schema validator against the XHTML 1.1 schema. Please open the validator from the Tools menu and select the XHTML files to validate, then click on the large button at bottom of the window. No errors means its a valid file.

When validating non-XBRL XHTML files, I get warnings about invalid XML nodes in the namespace of http://xbrl.org/2013/InlineXBRL

This happens because the XHTML documents contain iXBRL elements (taggings), which are unknown to the XHTML 1.1 schema. Those warnings can usually be ignored for separate financial statements that are not tagged. Please keep in mind, that only reports with no taggings, e.g. individual, separate non-consolidated reports must be validated with the XHTML validator. Those warnings will be displayed if the consolidated tagged financial statements will be accidentally validated.

When opening the XBRL report, I get an error message about too many errors, what can I do?

The following message box will be shown and no report will be loaded:

This error will be displayed, if there are more then 1000 validation messages raised by the XBRL validation. To solve this issue, just increase the number of errors allowed by changing the XBRL processor settings file.

Open the Auditor Settings from the main menu.
Switch to the Validation group
Set Maximum Number of Validation Messages to 1000000.
Click Apply + Close and restart the Auditor.

Where is "Jump-To-Fact" in the context menu?

You can now jump to facts by left clicking on the value you want to jump to.

Why does "Jump-To-Fact" sometimes not work?

Facts that are hidden in the XBRL report cannot be found by the "Jump-To-Fact" function. But hidden facts are always shown in the XBRL Report Data View.

There are two types of hidden facts:

Those officially included in the iXBRL document in the ix:hidden section. Those facts are usually hidden because its technical content is not reflected in the human readable report. Those facts are detected by check 14.
Facts that are "hidden" from web browser views by using CSS or HTML techniques. Those facts are usually forbidden by filing rules like the ESEF Reporting Manual.

To find out if facts are hidden in an older document, you can manually change the filing rules in the settings window to 2021 and then restart the auditor. Hidden facts are now displayed as errors in the validation messages. Please remember to reset the settings to automatic recognition of the filing rules.

Note: According to the ESMA Filing Rules of 2021, it is no longer allowed to hide facts in this way.

Why are some calculation inconsistencies WARNINGS and some are ERRORS?

XBRL reports (like ESEF) usually come with an entity specific Calculation Linkbase, that defines how totals in tables are calculated. If calculation inconsistencies are signalled, it means that the calculated value of a total differs from the actual reported value. However, some calculation inconsistencies are often unavoidable: Due to reporting of rounded values (e.g. to millions), small rounding differences are “common practice”. In order to distinguish rounding inconsistencies from real calculation issues (that usually indicate tagging issues), the AMANA XBRL Engine allows to enable a Calculation Linkbase Validation Severity Error Threshold, which must be configured in the XBRL (user based) settings. If the threshold is activated and set to e.g. 1%, it means that the all calculation inconsistencies where the delta is smaller than 1% of the rounded reported value are deemed to be WARNINGS, while all inconsistencies with differences bigger then the threshold are deemed to be ERRORS. If the threshold is not set, all calculation inconsistencies are signalled with a WARNING severity.

Further reading:

https://www.xbrl.org/esef-errors-and-common-pitfalls-8-rounding-and-calculations/

To activate this threshold you have to click on Settings>XBRL Processor Settings.

In the window you can mark the first option.

What is the meaning of the warning "The maximum XBRL reporting period columns have been reached, some periods are hidden"?

This warning will be shown if the number of periods in a report exceeds the maximum allowed number.
The periods are then no longer displayed in full in in the Tree View.
A complete display of all periods is then only possible in the Table View or in the Excel export.

I have checked off all the branches in the Presentation Linkbase Tree. Why do I still have Non-Audited Facts?

In some reports not all facts can be displayed completely in the Presentation Linkbase Tree. However, a complete listing of all facts is available in the Table View. Switch to the table view and check the outstanding facts using the function Check/Unckeck from the context menu. (Right Mouse Button). You can also drag over a range of table cells with the mouse to check several facts at once. In the Table View Cells with a green background are checked. Cells with a white background are still unchecked.

How can ESEF reports be digitally signed?

Ideally, ESEF report packages should by signed digitally by the auditors (and probably as well as by the company itself), to confirm the identity and prohibit changes of the final report. However, it seems there is no best-practice how to do this (using which signature, which file, etc.). The German auditors committee (IDW) decided in 2019 to work around this by recommending to embed the ESEF report package ZIP files into PDFs and then digitally sign the PDF files. However, this did not work out: After embedding a ZIP file in the PDF, its impossible to open it with Adobe Acrobat, due to security restrictions.

So instead, auditors started to include the hash sums of the ESEF files into the text of their auditors opinion, because this allows everybody as well to uniquely identify the files and to check if it is unchanged. Its important to know for preparers of ESEF reports, that it means that the ESEF ZIP file can’t be changed in any way after this hash sum has been calculated. However, this way is not ideal, because it would actually require that the auditors opinion is not part of the report package itself.

In the XBRL Auditor the SHA 256 hash sums are calculated for the ZIP and XHTML files:

Here is public tool that can use to calculate hash sums on any file:

https://emn178.github.io/online-tools/sha256_checksum.html

How can I check if XHTML tables are used in block tagging?

The XBRL Auditor offers multiple features to check the XHTML table tags being used in block taggings:

A dedicated new check 18 can be enabled in the Auditor settings. This check shows the number of XHTML tables in the whole document as well as per non-numeric tag:
The number of tables is displayed in the fact Properties in the XBRL Report Data View.
There you can also check if the escaped attribute is set correctly.
When right-clicking a cell in the Table View, the context menu item Show full fact value has an HTML view, that might visually render the table as well, if formatted accordingly.

The toolbar above the iXBRL Viewer can also be used to highlight XHTML tables in the report. It may be necessary to change the border width when the display is scaled. The color for the highlighting can be changed in the settings.

The number of XHTML tables per tag and the escaped attribute are displayed in the Excel report in a dedicated columns.

How to prove that XHTML table tags exist?

Please have a look at this section of our documentation.

How to use a local copy of the ESEF taxonomy?

Currently, there is a glitch at the ESMA website that prevents a taxonomy from being loaded from there.

Fortunately, you should have the taxonomies locally saved.

Please go to the XBRL Processor Settings in main menu under "Settings" and activate the options:

Cache downloaded files
Force offline cache usage for cached files

Please deactivate Disable binary Cache if this option is active.

If this is still not working maybe you don't have a working local taxonomy cache. You don't need ESMA to download it, we have it too.

https://downloads.amana-consulting.de/xbrl/tagger/Cache/XBRLCache.zip

Please extract the ZIP file to

YOUR USERNAME\AppData\Roaming\AMANAconsulting\XBRLCache

The AppData folder can be a hidden folder.