Ostovelkakirjanpitäjä tai kirjanpitäjä pitää kirjanpitojärjestelmässä kirjaa siitä, milloin ostolasku erääntyy, onko aikaisin maksamisesta saatavaa maksuhyvitystä hyödynnettävissä, ja uhkaako maksu myöhästyä. Se on seurantaa: päivämääristä koostuvan listan vertaamista kalenteriin ja toimenpiteisiin ryhtymistä, kun määräaika lähestyy. Kysymys on, voiko AI ottaa tämän hoitaakseen.
Tämä tehtävä saa pisteitä suotuisalta puolelta lähes kaikilla akseleilla. Rakenteisuus on korkea: eräpäivä on kiinteä arvo kiinteässä paikassa järjestelmässä, tulkintaa ei tarvita. Volyymi on suuri: yrityksessä, jolla on jatkuva ostolaskuvirta, niitä on satoja tai tuhansia vuodessa, kaikki samaa kaavaa noudattaen. Asiakaskontaktilla, fyysisillä toimenpiteillä ja luovuudella ei ole roolia; tämä on puhtaasti sisäistä, digitaalista, toistuvaa työtä. Juuri sen tyyppinen tehtävä, jota ohjelmisto on hoitanut jo pitkään, ja johon nyt myös AI-tyyppinen hälytysjärjestelmä soveltuu.
Poikkeus on virheiden kustannus, ja se korjaa kuvaa hieman. Unohtunut eräpäivä maksaa rahaa: maksuhyvitys menetetään, tai seuraa maksumuistutus ja mahdollisesti sakko tai vahingoittunut suhde toimittajaan. Harkintavalta ja vaatimustenmukaisuus saavat pisteitä keskiasemasta, ei koska tulkittavaa olisi paljon, vaan koska poikkeama — lasku, joka ei täsmää tilaukseen, maksuehto, joka on juuri muuttunut, toimittaja, joka jostain muusta syystä lykkää maksua — vaatii arviointia. Se ei ole luovaa työtä, mutta sitä ei voi täysin automatisoida ilman ihmistä, joka näkee poikkeuksen ja tekee päätöksen.
Kolme akselia, jotka tässä ratkaisevat, ovat rakenteisuus, volyymi ja virheiden kustannus. Kaksi ensimmäistä puoltavat vahvasti automatisointia: työ on riittävän säännöllistä ja riittävän yksinkertaista jätettäväksi ohjelmiston hoidettavaksi. Kolmas akseli hillitsee tätä: koska virhe maksaa rahaa, järjestelmän täytyy ei vain hälyttää vaan olla myös luotettava, ja tarvitaan ihminen, joka voi arvioida varoituksen ennen kuin maksu tosiasiallisesti suoritetaan.
Siksi tänään sopiva teknologia tähän on rpa: ohjelmisto, joka lukee eräpäivät, vertaa niitä maksukalenteriin ja tuottaa ilmoituksia tai valmistelee maksuehdotuksia. Ei itsenäisesti päättelevä AI, joka maksaa valvomatta, vaan automatisoitu seuranta, jossa ihminen käsittelee poikkeukset. Tämä on siirtymä, joka tapahtuu jo nyt monilla talousosastoilla: yleiskuvan ylläpitäminen on työtä, joka katoaa ostovelkakirjanpitäjän päivittäisistä tehtävistä, poikkeamista päättäminen jää.
Kaksi ehtoa määrittävät, toimiiko tämä tietyssä yrityksessä. Ensimmäinen on luotettava suunnitteludata: jos eräpäivät, maksuehdot ja hyvityssopimukset ovat oikein ja ajan tasalla järjestelmässä, automaattinen seuranta voi rakentua niiden päälle. Jos tiedot ovat hajallaan sähköposteissa, erillisissä sopimuksissa toimittajien kanssa tai järjestelmässä, joka ei liity kirjanpitoon, tarvitaan ensin siivoustyötä ennen kuin automatisoinnista on hyötyä. Toinen on poikkeamien havaitseminen: järjestelmän täytyy ei vain käsitellä vakiotapauksia, vaan myös osoittaa selvästi, kun jokin poikkeaa kaavasta, jotta ihminen voi arvioida sen.
Yrityksessä, jolla on pieni määrä vakiotoimittajia ja yksinkertaiset maksuehdot, seuranta on lähes täysin automatisoitavissa: vähän poikkeuksia, ennustettavat kaavat. Yrityksessä, jolla on paljon toimittajia, vaihtelevia sopimusehtoja, kansainvälisiä maksuja eri valuutoissa tai toistuvia laskuriitoja, tilanne on toinen: siellä poikkeamien todennäköisyys on suurempi ja arviointityötä jää rakenteellisesti enemmän jäljelle. Myös lähdedatan laatu tekee eron: hyvin järjestetty kirjanpitojärjestelmä antaa automatisoinnille enemmän tukea kuin järjestelmä, jossa on manuaalista syöttöä ja erillisiä Excel-listoja kirjanpidon rinnalla.
Tämä tehtävä ei ole irrallinen. Se liittyy laajempaan myynti- ja ostosaamisten avoimien erien yleiskuvaan, tiliotteiden lukemiseen ja täsmäytykseen, joilla maksut kirjataan pois, ja maksupalveluntarjoajien transaktioiden täsmäytykseen. Yhdessä nämä tehtävät muodostavat suuren osan yrityksen sisään tai ulos virtaavaan rahaan liittyvästä hallinnollisesta liikenteestä, ja kaikissa näissä tapauksissa pätee sama kaava: rakenne ja volyymi mahdollistavat automatisoinnin, virheiden kustannus ja poikkeukset ylläpitävät valvonnan muotoa.
Tämä ei ole henkilöstöneuvo eikä argumentti ostovelkaosaston pienentämisen puolesta. Se on kuvaus siitä, mikä osa tehtävästä on kahdeksan akselin mukaan soveltuva ohjelmiston hoidettavaksi, ja mikä osa jää ihmistyöksi. Jos tehtävien siirtymä vaikuttaa toimenkuviin, sovelletaan siihen omia lakisääteisiä vaatimuksia; katso myös selvitys siitä, milloin yrityksen yhteistoimintaelimen on osallistuttava keskusteluun. Mikään tässä ei takaa, että tehtävä tosiasiallisesti siirtyy ohjelmiston hoidettavaksi; se riippuu datan laadusta, järjestelmistä ja halukkuudesta huolehtia poikkeamien selkeästä havaitsemisesta.
Jotta näkisitte, miten tämä toteutuu omassa ostovelkaprosessissanne, kannattaa tarkastella laskuvirran laajuutta, toimittajien määrää ja sitä, missä määrin maksuehdot ja hyvityssopimukset on jo rakenteisesti kirjattu. FTE TO AI:n ilmainen pikaselvitys antaa siihen ensimmäisen suunnan: kaksitoista kysymystä, ei tiliä vaativaa, ja arvion siitä, kuinka suuri osa profiilinne tunneista on tänään AI:n hoidettavissa. Koko yrityksen työn tehtävätasolle purkava täysi työselvitys on vielä rakenteilla.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.