Assurance

The case company decided to acquire assurance on the ESEF report even though assurance was not mandatory. Interviewee 2 noted that the decision to acquire assurance was impacted by the recommendation by FIN-FSA. Assurance was acquired because the annual financial re-port with ESEF taxonomy would be the official document and the company wanted to ensure that the file was correct. The assurance was acquired in the fall 2020 before the announce-ment of postponeannounce-ment of ESEF reporting. The first meeting with the assurance provider was in November 2020. The ESEF requirements were outlined, and the assurance process was de-fined in the meeting.

”Of course it was clear from the beginning that we are responsible for reviewing [the tags]

and we also discussed if we needed assurance from auditors. And when Finnish Financial Su-pervisory Authority recommended assurance, it was quite clear that we would also acquire

it.” (Interviewee 2, 2021)

Interviewee 1 said that the assurance was beneficial because the mandate and the process was adopted for the first time. Interviewee 1 noted that the assurance gave them confidence that the tags were correct as internal expertise of tagging was limited. Interviewee 1 noted that the tag review brought out questions which also outlined the advantages of the assur-ance. In addition, because the process was new and some mistakes were found during the review, the assurance added value to the case company. Interviewee 1 also mentioned that the auditors had their own tool for validation, which the case company did not have, which helped to indicate possible validation errors.

Interviewee 2 said that assurance was useful, especially because the internal tag review re-quired a lot of work and because there were some questions that could then be discussed with the auditor and get support. The fact that also the auditor had gone through the same tags gave confidence that the tags were correct. Interviewee 2 thought that at first, when the assurance was first discussed, whether the assurance would add any value to the process as the tagging was outsourced and the service provider had ESEF know-how. But as the tagged

document was not finalized when the service provider initially provided the zip-file, Inter-viewee 2 noted that it was useful that the document was internally reviewed but also the auditor reviewed it.

“We noticed that the auditors were also doing [ESEF assurance] for the first time and not

everything was clear for them either. But of course, the fact that [auditors] probably do [as-surance] for multiple companies at the same time, their experience increases quite a lot

dur-ing the assurance process.” (Interviewee 2, 2021)

Auditor said that they started the actual assurance projects in August 2020 and Auditor noted there were some processes that needed to be re-evaluated and changed. The validation tool produced all the documentation needed for the assurance. Auditor pointed out that the tool will probably later next year produce 85% of the documentation for statutory auditing.

The main objective in the assurance, according to the Auditor, was that the reader of the an-nual financial report gave accurate view of the company. Auditor also pointed out that ensur-ing the technical quality was at good level was also important. However, the technical quality will be focused more next year and improved further. A big challenge was that the files were technically in different stages.

In November 2020, a meeting was arranged to define the ESEF process together with the as-surance provider. The key stakeholders were defined, and the process was mapped out in the meeting. The key stakeholders in the ESEF process were group reporting, service provider, IR and auditor. Auditor pointed out that they went through and validated the previous year fig-ures in the ESEF file during the fall so that the workload in the beginning of the next year could be reduced and validating the file would be easier. Auditor described the validation process as follows:

“The system takes [the document] from the zip-file and then the system makes certain tech-nical validations that have been defined in the system. Then we need to do manual checking

against audited annual financial report. So, we assure that the figures both in xHTML-docu-ment, which is in the zip-file, and the audited in annual financial report are the same.”

(Audi-tor, 2021)

The first XBRL zip-file was sent to the assurance provider after the initial tagging was done by the software vendor. The observations were discussed in a meeting in November 2020. The most common mistake was the balance type but also the correctness of the tags and sugges-tions for more suitable tags were discussed. The meeting was continued in December 2020 to go through issues in cash flow and equity statement. The observations from the two meet-ings were discussed with the service provider in December 2020. The observations from as-surance provider and comments from service provider were discussed internally in a meeting in December 2020. Last issues regarding the ESEF file were discussed with the assurance pro-vider in a meeting in January 2021 and the observations were sent to the service propro-vider to be fixed. In February 2021, the assurance provider noted that the tags were correct, and the file was technically valid. This was also communicated to IR department and decision to pub-lish the ESEF report as the official document was discussed.

Auditor noted that the ESEF files that had multiple errors, in comparison to the files that were correctly tagged, were the most time-consuming part in the assurance process. Auditor added that tags that were included in the IFRS taxonomy were quite easy to validate but unusual tags and reviewing cash flow statement could be time-consuming. Auditor noted that every com-pany had their own issues, and some issues were related to the same service provider but, at the time, no recurring problems had been identified and analysis regarding them was still on-going.

“We will probably come forward at some point what we have experienced [to be challenges].

But we have not had time yet [to analyze them]. We are still conducting [assurance] work so it is too early to have analysis on the most general [issues].” (Auditor, 2021)

Auditor said that the mandatory tags regarding company details should be discussed in na-tional level, for example, what should be included in them, and to unify the tagging and re-porting. Because the mandatory tags are linked to the RTS, every company interpreted it as well as they could as no clear instructions were available. Auditor also noted that the incon-sistencies were going to be discussed in the future. Furthermore, practices regarding ESEF reporting will evolve and will be defined in the coming years regarding this.

Auditor mentioned that the extension’s anchoring had been conducted in different ways and depended on the service provider. The detail level in which the anchoring had been done dif-fered between service providers and companies. In addition, some service provider systems had challenges with the anchoring. Auditor noted that materiality of the anchoring and prac-tical implementation will be more defined in the future. Auditor also hoped that more exam-ples regarding anchoring would become available, especially from more complex issues.

“Anchoring regarding extensions is like a wild west still and it feels that some service

provid-ers have their own view how it is done. In some places all of the anchors are combinations, and, in some places, there are less anchors. Then there are of course service providers that

have technical challenges with anchoring in [their] systems.” (Auditor, 2021)