ESEF Errors and Common Pitfalls: 4 – Report Package Errors
This is part of a series on common errors and pitfalls in ESEF filings, observed in our analysis of hundreds of reports collected in our repository, at filings.xbrl.org. For the series introduction, start here.
An ESEF report is made up of multiple files which must be submitted in a specially formatted ZIP file, known as a Report Package. Files within the Report Package ZIP file must be laid out in a specific way, which is defined by the Report Package Working Group Note. Although a Report Package is an ordinary ZIP file, the contents must be structured correctly as this is what enables XBRL software to automatically locate the XBRL report and other files within the ZIP.
Failing to conform to the prescribed Report Package structure is probably the most common error seen in ESEF filings, and is likely to lead to the report failing to open in XBRL software. Many of the filings on filings.xbrl.org have Report Package errors, and we have had to take additional manual steps to work around the errors and enable these filings to be loaded into the index.
Common examples of faulty Report Package construction include:
Multiple top-level files
Report Packages must have a single top-level directory inside the ZIP. Without this, software will not be able to automatically locate the XBRL files within the ZIP. For example, numerous filings have included a PDF file at the top level, which violates this rule.
Another common violation is the inclusion of a .DS_Store directory. This is a directory that is added automatically by the Mac OS operating system, and is usually an indication that the ZIP file has been edited manually after creation.
The best way to avoid these errors is to use XBRL Certified Software that generates and validates a Report Package, and to ensure that the package is not edited in any way after creation.
Incorrect path separators
The ZIP file specification requires that directories within the ZIP use / rather than \ as the directory separator. Unfortunately, some ZIP software incorrectly uses \, resulting in an invalid ZIP file.
As for the previous case, incorrect path separators are often an indication that the ZIP file has been edited manually, rather than generated by XBRL software.
Invalid taxonomy metadata
Report Packages include some standardised metadata that describes the included taxonomy (this is the taxonomyPackage.xml file).
The structure of this file is defined by an XML Schema, and the metadata must conform to this schema. An example of the type of metadata error seen is not using a two-digit ISO country code for the “publisherCountry” element, but instead using the country name (e.g. “Finland” rather than “FI”) or leaving the element empty.
Validation of this file should be enforced by XBRL creation software, but it is clear that not all software is doing this correctly. XBRL International is currently working to expand its software certification programme to ensure that this kind of validation is performed by report creation software. If you see this type of error listed against your report, you should contact your software provider.
Our guidance further explores best practices for constructing a taxonomy package.
