Kirjanpidon menetelmien kehittyminen haastaa lainsäädännön

Kirjanpitolain vuoden 2016 uudistuksessa lain toista lukua, joka säätelee kirjanpidon menetelmiä ja aineistoja, muutettiin ja selkeytettiin merkittävästi. Tavoitteena oli säätää teknologisen kehityksen hyödyntämistä mahdollistava säännöstö, jota seuraamalla varmistetaan luotettava ja tarkastettava kirjanpito. Kun uudistettujen säännösten soveltamisesta on nyt muutaman vuoden ajalta kertynyt kokemuksia, voi olla paikallaan tarkastella joitakin esiin nousseita kysymyksiä ja kehityksen kulkua.

Tositteiden ja aineistojen säilytyksen tiimoilta on aina riittänyt keskusteltavaa, ja viime aikoina muun muassa verkkokauppojen ja mobiilisovellusten myyntitositteet ovat aiheuttaneet päänvaivaa. Erilaisten tiedostostandardien rooli on ajankohtainen asia, ja robotiikan, koneoppimisen ja tekoälyn soveltaminen ovat viimeisen parin vuoden aikana nousseet voimakkaasti esiin myös taloushallinnon prosesseissa.

Uusi tositelaji lakiin

Vuoden 2016 lakiuudistus toi mukanaan uuden tositelajin, liitetietotositteet, joiden tarkoituksena oli varmistaa, että ne laskelmat ja asiakirjat, joihin liitetiedot perustuvat, säilytetään järjestelmällisesti niin että ne tarvittaessa löytyvät helposti. Tämä on pääsääntöisesti toiminut hyvin, mutta kannattaa muistaa, että tarkoituksena ei ollut lisätä byrokratiaa, vaan helpottaa sekä tilintarkastajien että kirjanpitovelvollisten elämää varmistamalla tällä tavalla tilinpäätösten liitetietojen laatua ja tarkastettavuutta. Kaikkien liitetietojen taakse ei muodon vuoksi tarvitse tulostaa tositetta ilman itsenäistä tietosisältöä – lakipykälän ”jollei sen perusta muuten ole ilmeinen” lievennystä kannattaisi hyödyntää enemmän.

Pienyrityksissä yhdeksi käytännölliseksi tavaksi selvitä liitetietotositteista on muodostunut, että liitetietojen yhteyteen – joko itse liitetietoihin tai erilliseen erittelyyn – merkitään lähdeviittaukset tyyliin ”Hallituksen pöytäkirja XX.XX.20XX”, ”Vuokrasopimus YYY/20XX” ja niin edelleen. Kunhan asiakirjat, joihin viitataan, säilytetään niin, että ne löytyvät yhtä hyvin kuin muutkin tositteet, niin muita toimenpiteitä ei tarvita. Jos perusta on muuten ilmeinen, esimerkiksi siksi että kyseessä on suoraan liitetiedosta ilmenevä arvostusperiaatteen valinta tai vastaava, tai vaikka havainto siitä, että työntekijöitä on kauden aikana ollut kolme, ei lisädokumentaatiota lähtökohtaisesti tarvita. Allekirjoittamalla tilinpäätöksen kirjanpitovelvollinen antaa liitetiedon ja vastaa siitä, että se on oikein.

Muista kuin liitetietotositteista laki toteaa, että tosite todentaa liiketapahtuman, ja että yhteys liiketapahtuman, tositteen ja kirjauksen välillä pitää voida todeta ilman vaikeuksia. Ajatuksena on, että tosite on se dokumentoitu tietosisältö, jonka kautta tiedetään liiketapahtumasta riittävästi, jotta voidaan tehdä kirjaus kirjanpitoon. Kirjanpitolain osalta tämä pitkälti riittää. Tositteen ei tarvitse todistaa, vaan todentaa eli dokumentoida. Tositteina käytetään paljon asiakirjoja, esimerkiksi myyntilaskuja, palkkalaskelmia ja sopimuksia, joihin kohdistuu sisältövaatimuksia muusta lainsäädännöstä. Näitä vaatimuksia pitää tietysti noudattaa. Muunkaan lain rikkominen ei ole hyvää kirjanpitotapaa, mutta kunhan liiketapahtumasta saadaan selville tarvittavat tiedot kirjauksen tekemiselle, niin kirjanpitolain vaatimukset tositteelle täyttyvät.

Viime aikoina on ollut jonkun verran pulmia isojen verkkokauppojen kautta myytyjen tuotteiden myyntitositteiden kanssa, kun on ollut hankala täsmäyttää loppuasiakkaille toimitetut tuotteet verkkokaupasta saatuihin koontimyyntiraportteihin – varsinkin, jos tuotteet ovat lähteneet verkkokaupan pitämästä etävarastosta. Kun keitokseen vielä lisätään palautukset, kuljetuskustannukset, alennukset ja provisiot, saattaa syntyä melkoinen soppa.

Samoin mobiililaitteiden sovelluskauppojen tai sovellusten sisällä myytyjen palvelujen eritteleminen ja täsmäyttäminen on tietyissä tapauksissa osoittautunut vähintäänkin haastavaksi. Tällaisissa tapauksissa voi käytännössä olla niin, että ainoana myyntitositteena on verkkokaupan tai sovelluskaupan yhteenvetotilitys, jolloin myyntikin joudutaan kirjaamaan niin kuin verkkokauppa tai sovelluskauppa olisi asiakas, vaikka se asiallisesti onkin ainoastaan välittävä osapuoli. Kirjanpitolautakuntaan ei vielä ole tullut tämänkaltaista tilannetta koskevaa lausuntopyyntöä, joten lausuntomuodossa olevaa ohjausta ei vielä ole.

Aineiston säilytys ja tarkastelu

Kirjanpitolain uudistuksessa luovuttiin aineistojen teknisiä säilytysmenetelmiä koskevasta ohjeistuksesta ja säädettiin yleisluontoinen velvoite säilyttää huolellisesti niin, että aineistoja pääsee tarvittaessa vaikeuksitta tarkastelemaan – sekä kauden aikana että sen jälkeen. Pitkäaikainenkaan säilyttäminen ei teknisesti tai taloudellisesti enää ole ongelmallista, kun hyvin varmistettujen S3-tyyppisten pilvitallennuspalvelujen hinnat ovat tätä kirjoittaessa laskeneet alle viiteen euroon per teratavu ja kuukausi. Huomiota kannattaa kuitenkin kiinnittää aineiston muotoon ja siihen, että sekä tiedostomuodot että niiden sisäinen ja keskinäinen rakenne on tarpeeksi selkeästi kuvattu.

Kirjanpitolain uudistuksessa luovuttiin aineistojen teknisiä säilytysmenetelmiä koskevasta ohjeistuksesta.

Tavoitteena pitää olla, että aineisto on vaikeuksitta tarkasteltavissa, kirjausketjuineen kaikkineen, ulkopuolisen asiantuntijan toimesta, sellaisessakin katastrofitapauksessa että sekä kirjanpitovelvollinen, tilitoimisto että ohjelmistotoimittaja ovat kaikki erikseen menneet konkurssiin useampi vuosi sitten. Vastuu tästä on selkeästi kirjanpitovelvollisella – toteutuksen voi toki sopimuksella ulkoistaa, mutta oikeudellinen vastuu säilyy.

Kirjanpidon aineistomuotoja on kolme pääluokkaa: Sisäiset rakenteelliset eli käytännössä ohjelmistosidonnaiset tietokannat; avoimien standardien mukaiset rakenteelliset (XBRL ja vastaavat, mutta periaatteessa myös esimerkiksi csv); ja tulostetyyppiset ei-rakenteelliset (melkein aina pdf). Sisäiset tietokannat ovat käteviä, kunhan niitä tuottanut ohjelmistokin on käytettävissä. Tulostetyyppiset täyttävät lain vaatimukset, mutta muiden kuin yksittäisten tapahtumien ja kirjausten jäljittäminen niistä on tolkuttoman työlästä.

Avoimien standardien mukaiset rakenteelliset tiedostot, joita voi lukea ja käsitellä yleisillä tietokanta- ja taulukkolaskentaohjelmistoilla, ovat periaatteessa paras valinta luotettavaa arkistointia varten. Niitä on kahta alalajia: Semanttiset rakenteelliset, joihin lukeutuvat erilaiset XBRL-tyyppiset tiedostot, ovat tiedostomuotoja, joissa tietokenttien merkitykset selviävät yksiselitteisesti ja standardisoidusti itse tiedostoista, yleensä viittaamalla erilliseen taksonomiaan, yhtenäistilikarttaan tai vastaavaan. Kenttämuotoiset rakenteelliset tiedostot, esimerkiksi Excel-tiedostot, csv-tiedostot ja vastaavat, vaativat tapauskohtaisesti erilaisia kuvauksia siitä, mitä eri kentät tarkoittavat ja liittyvät toisiinsa, jotta niiden tietosisältöä voisi ymmärtää ja hyödyntää.

Käytännössä säilytysmuoto riippuu pitkälti aineiston laajuudesta ja monimutkaisuudesta, ja tietysti siitä, minkälaisia tallenteita taloushallinnon ohjelmistosta saadaan. Suuren konsernin kirjanpitoaineistoja on hyvin vaikea arkistoida käyttökelpoiseen muotoon irrallaan sen taloushallinnon tietojärjestelmästä. Tämä ratkaisu kuitenkin toimii, koska isot yritykset hyvin harvoin kaatuvat niin äkillisesti ja lopullisesti että järjestelmiin ja tiedostoihin ei olisi pääsy, joskin ikäviä poikkeuksia tietysti saattaa tulla. Mikroyrityksen tai pienen yhdistyksen pienet aineistot voivat jopa olla helpommin tarkasteltavissa pdf-tulosteita selaamalla kuin rakenteellisia tiedostoja lukemalla.

Tilitoimistoa tai omaa ohjelmistolisenssiä käyttävä pieni tai keskisuuri yritys on tavallaan se hankala tapaus, kun tulostetyyppiset tiedostot eivät mahdollista järkevää tarkastamista, ja ohjelmistoon sidottujen tietokantatiedostojen käytettävyyttä ei ongelmatilanteissa aina voida taata. Semanttiset rakenteelliset tiedostostandardit eivät vielä ole niin valmiita ja vakiintuneita että niihin voisi turvautua, joten jos mahdollista, olisi hyvä varmistaa taloushallinnon tietojärjestelmän tallenteet hyvin dokumentoiduilla kenttämuotoisilla tiedostoilla, esimerkiksi csv-muodossa. Tämä tietysti vaatii sen, että ohjelmistosta pystyy tallentamaan sekä tiedostot että tarpeeksi selvän tiedostokuvauksen.

Kirjanpitolain näkökulmasta robotiikan käyttö ei ole ongelmallista, kunhan huolehditaan siitä, että kirjausketju säilyy.

Robotiikka, tekoäly ja kirjanpitolaki?

Parin viime vuoden aikana ohjelmistorobotiikkaa (RPA) on laajamittaisesti kokeiltu ja jonkun verran myös sovellettu tuotantokäyttöön taloushallinnon prosesseissa. Kyse ei vielä ole varsinaisesta tekoälystä, vaan pikemminkin makro- tai skriptipohjaisista apuvälineistä, joiden avulla simuloidaan näppäimistöä ja hiirtä käyttävää ihmistä verrattain tarkasti samalla tavalla toistuvissa työvaiheissa. Tyypillisiä sovelluskohteita ovat tapaukset, joissa yhdistellään ja siirretään tietoja usean eri ohjelmiston välillä – esimerkiksi niin, että tietyntyyppisen saapuneen tositteen perusteella tehdään tietynlainen kirjaus.

Kirjanpitolain näkökulmasta robotiikan käyttö ei ole ongelmallista, kunhan huolehditaan siitä, että kirjausketju säilyy. Se, tekikö kirjauksen ohjelmisto, robotti, tai ihminen ei ole oleellista, kunhan esimerkiksi tilintarkastaja pystyy tositteen ja kirjanpidon avulla näkemään ja ymmärtämään miten ja millä perusteella kirjaus on tehty. Jos kirjaus perustuu laskelmiin, ovat nämä laskelmat – tai niiden kaavat – tositeaineistoa, sikäli kun niitä tarvitaan, jotta kirjauksen voi ymmärtää ja tarvittaessa toistaa. Tämä pätee täysin samalla tavalla riippumatta siitä, onko kirjaus tai kirjanpidon muu vaihe teknisesti toteutettu happea hengittävän vai sähköä kuluttavan käyttäjän toimesta.

Toinen asia on, että kokemukset ohjelmistorobotiikan soveltamisesta taloushallinnon prosessivaiheisiin ovat olleet vähintäänkin vaihtelevia. Robotti, joka on ohjelmoitu tai opetettu käyttämään useaa eri ohjelmistoa niin kuin se olisi ihminen, on huomattavan hauras ratkaisu. Heti kun jokin asia jossain sen käyttämän järjestelmän käyttöliittymässä muuttuu, lakkaa robotti tyypillisesti toimimasta, ja pitää ohjelmoida tai kädestä pitäen opettaa uudestaan.

Robotin toimintalogiikkaa on monessa tapauksessa hankala dokumentoida selkeästi ja hyvin, mikä tekee niiden uudelleen ohjelmoimisesta tai opettamisesta haastavaa, kun aikaa on kulunut ja ihmiset ovat vaihtuneet. Isot yritykset, jotka ovat soveltaneet ohjelmistorobotiikkaa laajasti, ovat nyt heräämässä tilanteeseen, jossa on käsillä itse (ja nopeasti!) aiheutettu useiden kymmenien tai satojen hauraiden ja huonosti läpinäkyvien legacyjärjestelmien soppa. Ohjelmistorobotti on poikkeuksetta huonompi ratkaisu kuin järjestelmien integrointi, ja jos eri järjestelmät ja organisaatiot voivat siirtää tietoja keskenään luotettavien avoimien standardien mukaisissa rakenteellisissa tiedostoissa, ei robotiikkaa enää näissä prosessivaiheissa tarvita.