Euroopan arvopaperimarkkinaviranomainen (European Securities and Markets Authority, ESMA) julkaisi heinäkuussa päivityksen ESEF Reporting Manual -ohjeeseen. Alla ensimmäisiä havaintoja ja ajatuksia päivityksestä. Päivitys ei sisällä rakenteellisesti merkittäviä uudistuksia, mutta muutama kohta herätti huomiomme.
IFRS-taksonomian käyttö laajennuksissa
Guidance 1.2.1 Use of taxonomy elements corresponding to IFRS standards or interpretations10 that are not yet adopted in the EU -kohdassa käsitellään IFRS-taksonomian käyttöä laajennuksissa. ESMA suosittelee käyttämään IFRS-taksonomian tägejä laajennuksina, jos kyseistä tägiä ei ole ESEF-ydintaksonomiassa, esimerkkinä tägi "issuer_prefix:PropertyPlantAndEquipmentIncludingRightofuseAssets". Raportointimanuaalin päivitetyssä versiossa todetaan, ettei kyse ole pakottavasta säännöstä. Mielestämme tämä on hyvä suositus, eikä se ollut pakottava sääntö tulkintamme mukaan myöskään edellisessä versiossa. Tuntuu siltä, että tässä ja ehkä muutamassa muussakin kohdassa ESMA käy ”keskustelua” raportointimanuaalin käyttäjien kanssa selventääkseen näkökantaansa.
Vuoden viimeinen päivä on myös nykyisen vuoden ensimmäinen päivä
ESMA on selventänyt päivämäärän 31.12.xxxx merkitystä. Edellisen vuoden viimeinen päivä on myös nykyisen vuoden ensimmäinen päivä. Lähtökohtaisesti tägäyksissä ei käytetä 1.1.xxxx päivämäärää, vaikka se lukisi silmin luettavassa dokumentissa. Tämä löytyy kohdasta Guidance 2.1.2 Formatting of the period element in the context of the Inline XBRL document.
Päälaskelman tyhjien kohtien tägääminen
Guidance 2.2.5 Tagging of dashes or empty fields -kohdassa annetaan suosituksia päälaskelmien tyhjien kohtien tägäämisestä. Muiden päälaskelmien kuin oman pääoman muutoslaskelman kohdalla ohjeistus on selkeä, ja mukailee käsityksemme mukaan viime vuotta. Tyhjät rivit ja solut tägätään myös, olipa niissä viiva, väli tai jokin muu merkki. Oman pääoman muutoslaskelman suositus on kuitenkin hieman vaikeaselkoinen, eikä se ensimmäisellä kerralla luettaessa antanut täyttä selvyyttä käytännön tasolla. Tätä kirjoittaessa selvitystyömme ja tulkintamme kyseisestä suosituksesta on vielä kesken.
Taulukoiden luettavuus
Guidance 2.2.6 Readability of the information extracted from a block tag -kohdassa käsitellään text blog -tägejä. Taulukoiden luettavuus on yksi kolmesta pääasiasta, eli niiden muuttaminen ”tekstimössöstä” taulukoiksi tägien fact valuen kohdalla olisi viimeistään nyt ajankohtaista. Toki tekstin kappaleiden järjestyksen tulisi myös noudattaa silmin luettavan dokumentin järjestystä.
Tiedostojen nimeäminen
Ylivoimaisesti mielenkiintoisin muutos on tiedostojen nimeäminen, jota käsitellään Guidance 2.6.3 Naming convention for report packages and report file -kohdassa. Raporttipaketin, joka on zip-tiedosto, nimeämissuositus on muuttunut:
- Viime vuonna tiedosto nimettiin {base}-{date}-{lang}.zip
- jossa base on LEI tunnus tai yhtiön nimi/lyhenne nimestä
- Uusi nimen muodostus on {base}-{date}-}-{version}-{lang}.xbri
Ylimääräinen sulkumerkki date- ja version-määreiden välissä on todennäköisesti kirjoitusvirhe. Vanha zip-pääte on korvattu xbri-päätteellä. Huomaathan että tiedoston tunnus voi edelleen olla ”zip”. Lisäksi nimessä tulee jatkossa olla versionumero. Ensimmäinen versio on nolla, ja jos paketti täytyy julkaista uutena versiona, luku kasvaa yhdellä. Suurin versionumero on yhdeksän, eli yrityksille sallitaan kymmenen yritystä.
Versionumerointi on uusi piirre, eikä mieleemme tule muita julkaistavia dokumentteja, joissa se olisi käytössä. Tämä saattaa aiheuttaa teknisiä haasteita. Seuraamme mielenkiinnolla, miten tämä käytännössä toteutuu esimerkiksi OAM:n tietokannassa, jota Nasdaq ylläpitää. Versionhallinnan vaikeus tulee ensimmäisenä mieleen; mistä tietää, että käsissä on viimeinen versio raportista? Versionumero tulee myös html-, htm- tai xhtml-päätteisen raportin nimeen, muut raporttipaketin tiedostonimet pysyvät samoina. Olisi mielenkiintoista tietää, miksei kaikkien tiedostojen nimiä muutettu samalla.
Esitystapaeroista johtuvat laskentavirheet
Guidance 3.4.1 Documenting arithmetical relationships in the calculation linkbase -kohdassa on päivityksessä todettu, että laajan tuloslaskelman ja oman pääoman muutoslaskelman esitystapaeroista johtuvat laskenta”virheet” eivät ole virheitä ja ne voi jättää huomioimatta. Mielestämme tämä on huono muutos. Käytännössä tästä eteenpäin muiden laajan tuloslaskelman erien ryhmittelyt voivat olla erilaiset päälaskelmissa.
Lopuksi
Poimimme ylle raportointimanuaalin päivityksen keskeisimmät muutokset ensimmäisen lukukerran jälkeen. Kuten aina, muutokset sisältävät jotain hyvää, ja ehkä jotain vähän vähemmän hyvää. Lähempi tutustuminen saattaa vielä muuttaa näkemyksiä.
Kuinka voimme auttaa?
Toimimme asiakkaidemme apuna ja neuvonantajana raportointimuutosten seurannassa ja uusien vaatimusten käyttöönottamisessa. Avustamme mielellämme yritystäsi ESEF-raportointiin liittyvissä asioissa.