Verkkolasku­datan haasteet kirjan­pidon automatisoinnissa

Laskujen sisältämää dataa käytetään yrityksissä useassa laskun käsittelyn vaiheessa. Laskun hyväksyntävaiheessa oleellisia ovat sellaiset tiedot, joiden perusteella laskujen käsittelijät voivat päätellä, mihin liiketapahtumaan lasku liittyy. Tällaisia ovat muun muassa laskun lähettäjä nimi, sopimusnumero, tilausnumero tai -viite sekä mahdolliset seurantakohteet. Logistiikan näkökulmasta taas esimerkiksi tuoterivit ja niihin liittyvät yksityiskohtaiset tiedot, kuten tuotenumero, yksikköhinta ja kappalemäärät, ovat oleellista informaatiota. Lopulta lasku käsitellään kirjanpidossa, jossa taas kirjanpidon tilin ja tositepäivän valintaan sekä arvonlisäveron käsittelyyn vaikuttavat tiedot ovat olennaisia. Verkkolaskuformaatissa on määritelty edellä mainituille tiedoille kohdat, joihin prosessin eri vaiheiden automatisointi voidaan perustaa.

Jos tiedot eivät tule verkkolaskuformaatissa määritellyssä muodossa, automatisoinnista tulee haastavaa. Tietoja joudutaan ohjelmallisesti etsimään laskuttajakohtaisesti eri paikoista tai pahimmassa tapauksessa käsittelemään lasku aina manuaalisesti. Ei siis ole yhdentekevää, noudatetaanko verkkolaskuformaattia ohjeistuksen mukaisesti, mikäli haluamme edistää automaatiota laskun käsittelyn jokaisessa eri vaiheessa. Halusimme selvittää, millaisia puutteita verkkolaskudatassa on nimenomaan kirjanpidon automatisoinnin näkökulmasta, ja kävimme läpi noin sadan toimittajan lähettämät Finvoice-formaatissa olevat verkkolaskut.

Laskun kuva ja verkkolaskudata eivät aina vastaa toisiaan

Kirjanpidon automaation kannalta on tärkeää, että verkkolaskudata sisältää samat asiat, joita laskun käsittelijä hyödyntää laskun kuvalta ja sen liitteistä (muun muassa laskun lähettäjä, tuote tai palvelu, toimitusaika ja ALV-käsittely). Lisäksi laskulla olevia tietoja on pystyttävä yhdistämään toisiinsa, esimerkiksi tuotteeseen sen hinta. Näiden tietojen esittäminen digitaalisessa muodossa on mahdollistettu verkkolaskuformaatin rakenteen kautta. Vaikka verkkolaskuformaatit mahdollistavat yksityiskohtaistenkin tiliöintiohjeiden lisäämisen dataan, vaatii hyvä data myös paljon laskun laatijalta ja laskutusohjelmistolta. Verkkolaskudatan validoinnillakaan ei voida poistaa kaikkia virheitä tai puutteita datasta, mistä esitämme esimerkkejä tässä artikkelissa.

Läpikäydyistä laskuista noin puolet oli automaation kannalta ihanteellisia. Laskuilta löytyivät perustiedot laskuttajasta ja laskun saajasta, arvonlisäverotiedot, tuotetiedot, toimitus- ja laskutusajankohdat sekä muut laskulla näkyvät lisätiedot. Sen sijaan lopuissa laskuista oli jonkinlaisia puutteita, yleisimpänä se, että tiedot löytyivät laskun kuvalta selkeästi ja kirjanpidon näkökulmasta oikein, mutta verkkolaskudatasta emme samoja tietoja löytäneet (verkkolaskudataa ei aina muodosteta laskun kuvan mukaisesti, vaan usein kuvalle saatetaan tuottaa laskutusohjelmistosta enemmän tietoa kuin verkkolaskudataan päätyy). Tämä puutteellinen data esti joko kokonaan tai osittain tiliöintiautomatiikan, varsinkin jos tosite olisi täytynyt kirjata esimerkiksi usealle eri kirjanpidon tilille tai seurantakohteelle.

Oikeanlainen verkkolaskudata sisältää samat asiat, joita laskun käsittelijä hyödyntää laskun kuvalta ja sen liitteistä. Näitä ovat esimerkiksi laskun lähettäjän ja vastaanottajan tiedot sekä laskun perustiedot.

Arvonlisäverotiedot ovat kirjanpidon kannalta tärkeimpiä tietoja.

Kaikista kriittisimmät puutteet liittyivät tietojen virheelliseen ilmoittamiseen verkkolaskudatassa tai jopa puuttumiseen kokonaan. Näistä merkittävin liittyi arvonlisäverotietoihin. Virheellisimmässä löytämässämme laskussa oli ilmoitettu arvonlisäverotiedot verkkolaskudatassa mutta niitä ei näkynyt laskun kuvalla. Laskun sisällön perusteella laskulla ei arvonlisäveroa pitänyt ollakaan, joten löytö herätti huolta, perustuuko verkkolaskudata aina laskumerkintöihin lainkaan.

Muissa läpikäymissämme laskuissa arvonlisäverotiedot eivät sinänsä olleet virheelliset, mutta ne oli saatettu ilmoittaa puutteellisesti verrattuna laskun kuvalla näkyviin tietoihin. Esimerkiksi rivitiedon arvonlisäverotiedoiksi oli ilmoitettu vain tuotteen nettosumma sekä arvonlisäveron määrä, jolloin bruttosumman ja arvonlisäveroprosentin selvittäminen jää vastaanottajan tehtäväksi, vaikka verkkolaskuformaatissa on myös selkeästi paikat näillekin tiedoille.

Kuvassa oikein ilmoitetut arvonlisäverotiedot. Laskun kuvalla riveittäin näkyvät tuotetiedot ja niiden arvonlisäverot on myös verkkolaskudatassa pystyttävä selkeästi erottelemaan toisistaan ja sisällyttämään dataan.

Toinen kriittinen esimerkki liittyi joidenkin toimittajien hyvityslaskuihin, joilla verkkolaskudatassa (ja usein myös laskun kuvalla) viitattiin hyvitettävään laskuun, mutta itse hyvityslaskulla ei ollut mainintaa hyvitetyistä tuotteista. Samoin jollakin laskulla saatettiin viitata tarkempaan tuotekohtaiseen erittelyyn erillisessä liitteessä tai sopimuksessa. Tällaisten laskujen automatisoiminen on mahdotonta avaamatta alkuperäistä laskua tai liitettä. Näissäkin tapauksissa hyvitettävät tai veloitettavat tuotteet tulisi esittää verkkolaskuformaatin mukaisesti itse laskulla ja laskun datassa, jolloin ne voitaisiin käsitellä suoraan avaamatta erillisiä dokumentteja.

Selvityksemme perusteella myös rivitiedoissa oli paljon puutteita. Joidenkin toimittajien laskuilla eri tuotteita ei ollut ilmoitettu omina tuoteriveinään, vaan ne oli listattu yhdeksi riviksi niin, että tuotekohtaiset hinnat oli lueteltu tuotekuvauksen tekstissä ja kaikkien tuotteiden kokonaishinta oli rivitiedon summa. Näin oli esimerkiksi joissakin osamaksuvelan laskuissa, joissa korko, kulut ja lyhennys oli esitetty yhtenä tuoterivinä ja niiden summat yhteensä rivitiedon summana. Kirjanpidon näkökulmasta tällaista laskua ei pysty automatisoimaan (ilman kuvatulkintaa), koska korot, kulut ja lainan lyhennys kirjataan omille tileilleen, jolloin ne tulisi esittää omina tuoteriveinään verkkolaskudatassa. Datasta pitäisi selvitä tuotteen rivisumman lisäksi jokaisen tuotteen arvonlisäverotiedot. Tämäkään ei toteudu, mikäli eri tuotteita yhdistetään yllä mainitulla tavalla samaan rivitietoon.

Ylemmässä kuvassa on esimerkki virheellisesti laaditusta verkkolaskudatasta, jossa eri hintaiset tuotteet on yhdistetty samaan tuoteriviin. Alemmassa kuvassa on esimerkki, kuinka tuoterivit tulisi esittää omina tuoteriveinään, jotta kirjanpidon automaatio toimii.

Myös päinvastaisia esimerkkejä osamaksuvelan laskuista löytyi. Osalla laskuista rivitiedot oli ilmoitettu liiankin erillään, jolloin samaan tuotteeseen liittyvä tieto oli hajotettu useaksi eri rivitiedoksi. Esimerkiksi osamaksuvelan kohteena olevat laitteet oli listattu omina rivitietoinaan ja niihin liittyvät lyhennykset ja kulut ominaan. Kirjanpidossa täytyy pystyä yhdistämään oikean laitteen lyhennys oikeaan velkaerään. Näissä laskuissa tietojen yhdistäminen toisiinsa datan perusteella on mahdotonta, mutta laskun kuvalta katsottuna se onnistuu.

Lähes yhtä merkityksellisiä olivat sellaisten toimittajien laskut, joissa tuoterivejä oli kymmenittäin, jolloin tositteen tiliöinnissä helpointa olisi käyttää tuoteryhmäerittelyä. Usein kirjanpidon tiliöinti ja raportoiminen asiakkaalle olisi riittävää tuoteryhmätasolla. Myös esimerkiksi ravintola-alalla viranomaisilmoitukset vaativat tuoteryhmäkohtaista erittelyä tiettyjen tuotteiden osalta. Jos nämä ilmoitukset laaditaan kirjanpidon yhteydessä, sen toteuttaminen voi vaatia kirjanpitäjältä todella tarkkaa tuntemusta yksittäisistä tuotteista, minkä lisäksi tietojen kerääminen yksittäisiltä riveiltä kymmenien tuoterivien laskuista on manuaalista työtä. Havaintojemme perusteella useimmilta laskuilta tuoteryhmätiedot löytyivät laskun kuvalta, mutta verkkolaskudatassa tiedot vaihtelivat. Osalla tuoteryhmätietoa ei ollut lainkaan ja niillä, joilla tiedot löytyivät, ne olivat datassa eri kohdassa kuin toisilla toimittajilla. Finvoice-formaatissa on määritetty oma kohtansa tuoteryhmien kokoamiselle, mutta havaintojemme perusteella laskun lähettäjät eivät sitä käyttäneet.

Tuoteryhmittely on erityisen tärkeää muun muassa ravintola-alan laskuilla. Alkoholiostot tulee ilmoittaa anniskelun puolivuotisilmoituksella ja ilmoitettavat tiedot perustuvat usein kirjanpitoon. Tuoteryhmittelyn avulla kirjanpitäjä kohdistaa alkoholiostot oikeille kirjanpidon tileille. Jos verkkolaskudata ei sisällä tuoteryhmittelyä, automatisointi ei onnistu.

Pienemmät mutta automatisoinnin kannalta merkittävät virheet liittyivät laskutusjakson tai toimituspäivän ilmoittamiseen sekä seurantakohdemerkintöihin. Laskutusjaksoa/toimituspäivää käytetään suoriteperusteisessa kirjanpidossa oikean tositepäivän määrittämiseen tai summaltaan olennaisten laskujen jaksotusrajojen selvittämiseen. Jos tieto ei ole käytettävissä tai se on eri toimittajilla eri paikassa, laskujen automatisoiminen ei aina ole mahdollista.

Havaintojemme perusteella suurimmalla osalla laskuista tieto löytyi verkkolaskuformaatin mukaisesta kohdasta, mutta osalla laskuista laskutusjakso tai toimituspäivä oli ilmoitettu tuotekuvauksessa. Pahimmillaan tällaiset laskut on kirjattava kuukausittain manuaalisesti, vaikka päivämäärätieto olisi verkkolaskudatassa saatavilla. Pelkkä rakenteellinenkaan muoto ei siis aina mahdollista automaatiota, jos tietoa ei voi käyttää sen tarkoittamalla tavalla.

Laskun laatija ei välttämättä näe, tukeeko ohjelmisto voimassa olevaa verkkolaskuformaattia tai miten laskutusohjelman eri kentät muodostavat verkkolaskudataa. Ohjelmistojen täytyy olla yksiselitteisiä käyttäjälle, koska laskuja voi laatia esimerkiksi yksityisyrittäjä, jolla ei ole resursseja opiskella standardeja. Isoja laskumassoja lähettävän toimijan on kuitenkin hyvä perehtyä omaan laskutusjärjestelmään myös verkkolaskudatan osalta.

Seurantakohteet tuovat vielä oman mausteensa laskujen automatisointiin. Jotta oikean tiliöinnin lisäksi kirjanpidossa voidaan tuottaa sisäistä laskentaa, täytyisi seurantakohteillekin löytää vakioitu paikka verkkolaskudatassa. Selvityksemme perusteella käytäntö on kirjava: osalla seurantakohde löytyi tuotekuvauksesta, mikäli seurantakohde vaihteli tuotteittain. Jos seurantakohde koski koko laskua, käytettiin usein ostajan viite -tietoa. Finvoice-formaatissa on määritetty oma paikkansa seurantakohteille jopa yksittäisille tuoteriveille asti, mutta havaintojemme perusteella sitäkään ei käytetty.

Laskun kuvalla ei saisi olla sellaista tietoa, jota verkkolaskudatasta ei löydy

Jos riittävät tiedot verkkolaskudatassa ovat kohdallaan, voi nykyisillä teknologioilla saavuttaa lähes 100 prosenttisen kirjanpidon automaation, sillä kone pystyy käsittelemään tietoa laskun datasta samalla tavalla kuin laskun käsittelijä laskun kuvalta, ja siten päätymään samaan lopputulokseen. Yleisesti siis ajatus verkkolaskudatan osalta pitäisi olla, että mitä tahansa laskulla näkyvää tietoa voidaan käyttää tiliöintiin, eli laskun kuvalla ei saisi olla sellaista tietoa, jota ei verkkolaskudatasta löydy. Vaikka tekoäly kehittyy kovaa vauhtia, ei jo rakenteisessa muodossa olevalle laskulle kannata tehdä kuvatulkintaa, jotta loputkin olennaiset tiedot saadaan automatiikan käyttöön. Verkkolaskudatan pitäisi olla itsessään jo laadukasta.

Johtopäätöksenä voimme todeta, että verkkolaskudatan laadun merkitystä ei ymmärretä vielä täysin, sillä verkkolaskuformaattia ei käytetä laskujen laadinnassa kaikilta osin ohjeistuksen mukaisesti. Tämä voi myös johtua ohjelmistoista, joilla laskuja laaditaan: laskun laatija ei välttämättä pysty lisäämään kaikkia haluamiaan tietoja niihin varattuihin kenttiin, jos laskutusohjelmisto ei sitä mahdollista. Ennen kaikkea selvitys osoittaa, kuinka tärkeää standardien laatiminen on. Jotta yhä enemmän digitalisoituvassa maailmassa dataa voidaan hyödyntää laajasti, tiedon on oltava yhtenäisessä muodossa ja eri sidosryhmien tarpeet huomioituna.