Talousraportoinnin automatisointi vaiheittain

Mistä käsityö oikeasti syntyy

Tyypillinen kuukausiraportti syntyy näin: joku kirjautuu taloushallinnon järjestelmään, ottaa pääkirjan ulos, avaa viime kuun taulukon, liittää uudet luvut ja tarkistaa että summat täsmäävät. Sen jälkeen luvut jaotellaan raporttiriveille, budjetti liitetään viereen ja kokonaisuus lähetetään eteenpäin PDF:nä.

Automatisoinnin suunnittelu alkaa koko työketjun tarkastelusta. Aikaa voi kulua aineiston saamiseen, tilien kohdistamiseen, budjetin yhdistämiseen, lukujen täsmäyttämiseen tai muutosten selvittämiseen. Työläin vaihe riippuu organisaation järjestelmistä ja raportointitavasta.

Rajapintaintegraatio vähentää tiedon siirtämisen käsityötä. Raportin luotettavuus edellyttää lisäksi sovittuja laskentasääntöjä, historiakorjausten käsittelyä ja valvontaa. Tavoitteena on automatisoida hallittu kokonaisuus.

Automatisoi vasta kun raportista on sovittu

Sopikaa raportin käyttäjät, päätökset ja hyväksymiskriteerit ennen toteutusta. Näin tiedonsiirrot ja datamalli voidaan rakentaa oikeaan käyttötarpeeseen.

Tavallisia lähtökohtia ovat tuloksen vertailu budjettiin, poikkeamien syyt, kassatilanne ja vastuualueiden kehitys. Kansainvälisessä tai usean yhtiön ympäristössä tarvitaan lisäksi yhteiset periaatteet esimerkiksi valuutoille, tilikarttojen eroille ja konsernin sisäisille erille.

• Kuka raporttia lukee: hallitus, toimitusjohtaja ja talouspäällikkö tarvitsevat eri tarkkuustason.
• Millä tarkkuudella: yhtiö, kustannuspaikka, projekti vai kaikki kolme.
• Mitä verrataan: budjettiin, edelliseen vuoteen, ennusteeseen vai kaikkiin.
• Millä viiveellä raportti on riittävän hyvä. Kolmantena arkipäivänä valmis raportti on eri toteutus kuin reaaliaikainen.
• Kuka omistaa jokaisen rivin määritelmän. Käyttökate lasketaan eri tavoilla, ja se pitää päättää kerran.

Rajapinta, tiedostosiirto vai käsin toimitettu aineisto?

Rajapinta mahdollistaa tiedon hakemisen ohjelmallisesti sovituilla rajauksilla. Ajastettu tiedostosiirto voi olla yhtä tarkoituksenmukainen, jos lähdejärjestelmä tuottaa tarvittavan aineiston luotettavasti ja tiedostojen valmistuminen voidaan todeta.

Molemmissa toteutuksissa tarvitaan aineiston tunnisteet, duplikaattien käsittely, sisältötarkistukset ja turvalliset uudelleenajot. Valinta tehdään saatavilla olevien tietojen, päivitysviiveen, kustannusten ja ylläpidon perusteella.

Käsin toimitettu aineisto voi sopia ensimmäiseen kokeiluun tai harvoin päivittyvään taustatietoon. Silloinkin tiedostomuoto, toimitusvastuu ja puuttuvan aineiston käsittely kannattaa sopia.

• Rajapintasiirron toteutus Pythonilla ja Cloud Runilla

Fennoan rajapinta käytännössä

Fennoan API v1:n Accounting API tarjoaa raportointiin esimerkiksi pääkirjan, tilikartan, kauden lukitustietoja ja budjetteja. Alla oleva accounting_api-esimerkki koskee tätä versiota. Fennoa julkaisee API v2:ta vaiheittain: tarkistakaa uuden integraation tarvitsemien toimintojen saatavuus ja siirtymäsuunnitelma ennen toteutusta.

Tunnukset luodaan Fennoassa erillisenä API-käyttäjänä valikosta Käyttäjät → Luo uusi API-käyttäjä, ja luonti vaatii pääkäyttäjäoikeudet. Käyttäjätunnus ja avain näytetään vain kerran luonnin yhteydessä: jos ne katoavat, käyttäjä on poistettava ja luotava uudelleen. Ottakaa ne siis heti talteen salaisuuksien hallintaan, älkääkä sähköpostiin.

Selvittäkää ympäristön ylläpitäjän tai tilitoimiston kanssa käyttöoikeudet, mahdolliset maksut ja testiympäristö ennen toteutuksen aikatauluttamista. Rajatkaa raportointi-integraation oikeudet tarvittaviin lukutoimintoihin.

• Fennoan API-versiot, julkaisusuunnitelma ja testiympäristö

import os, requests

# Osoitteen ja autentikoinnin tarkka muoto: katso Fennoan tietopankki.
# Tunnukset ympäristömuuttujista, ei koskaan koodiin.
BASE = os.environ['FENNOA_BASE_URL']
AUTH = (os.environ['FENNOA_API_USER'], os.environ['FENNOA_API_KEY'])

def paakirja(alku, loppu):
    r = requests.get(f'{BASE}/accounting_api/get/ledger/{alku}/{loppu}',
                     auth=AUTH, timeout=60)
    r.raise_for_status()
    return r.json()

# Tämä on se kutsu, joka kannattaa hakea ennen kaikkea muuta:
# se kertoo mihin asti kirjanpito on lukittu. Lukitus rajoittaa muutoksia, mutta kausi voidaan avata uudelleen;
# seuraa lukitustilan muutoksia ja mahdollista historian korjausajo.
def lukitustilanne():
    r = requests.get(f'{BASE}/accounting_api/get/locking_periods',
                     auth=AUTH, timeout=30)
    r.raise_for_status()
    return r.json()

Procountorin rajapinta käytännössä

Procountorin rajapinta on REST-muotoinen ja käyttää JSONia, ja autentikointi tehdään OAuth 2.0:lla. Tarjolla on kaksi kulkua: client credentials -kulku konetta varten sekä authorization code -kulku käyttäjän puolesta toimimiseen. Procountor suosittelee taustaintegraatioihin client credentials -kulkua. Se tarvitsee client-tunnusten lisäksi käyttäjään, yritykseen ja integraatioon sidotun API-avaimen. Saatu tunniste ei ole sidottu tiettyyn rajapintaversioon.

Raportoinnin kannalta keskeisiä ovat tositteet eli ledger receipts. Yksittäisiä tositteita voi hakea tunnuksella, ja tiheästi käytetyille resursseille on erikseen eräpäätepisteet, joilla saa haettua jopa 200 resurssia yhdellä kutsulla. Sivutus toimii kahdella tavalla: joko kertomalla viimeksi saadun tunnisteen previousId-parametrilla tai antamalla sivukoko ja sivunumero. Oletussivukoko on tyypillisesti 50.

Rajapinnassa on ympäristökohtaiset kutsurajat: dokumentaatiossa tuotannolle ilmoitetaan 60 pyyntöä sekunnissa asiakasta kohden ja julkiselle testipalvelimelle 90 pyyntöä minuutissa. Tarkistakaa ajantasaiset rajat ja toteuttakaa sivutus, viiveelliset uudelleenyritykset sekä 429-vastausten käsittely.

• Procountorin tunnistautumistavat
• Procountorin rajapinnan käyttörajat ja yleiset ohjeet

import os, requests

# Tarkat osoitteet ja parametrit: dev.procountor.com.
TOKEN_URL = os.environ['PROCOUNTOR_TOKEN_URL']
API       = os.environ['PROCOUNTOR_API_URL']

def token():
    r = requests.post(TOKEN_URL, timeout=30, data={
        'grant_type':    'client_credentials',
        'client_id':     os.environ['PROCOUNTOR_CLIENT_ID'],
        'client_secret': os.environ['PROCOUNTOR_CLIENT_SECRET'],
        'redirect_uri':  os.environ['PROCOUNTOR_REDIRECT_URI'],
        'api_key':       os.environ['PROCOUNTOR_API_KEY'],
    })
    r.raise_for_status()
    return r.json()['access_token']

def tositteet(alku, loppu):
    """Hae tunnukset ID-järjestyksessä ja nouda täydet tositteet erissä.
    Tuotannossa lisää 429/5xx-uudelleenyritykset ja tokenin uusinta.
    Sivutus ei muodosta muuttumattoman aineiston tilannevedosta."""
    headers = {'Authorization': f'Bearer {token()}'}
    previous_id, kaikki = None, []
    while True:
        params = {'startDate': alku, 'endDate': loppu, 'size': 200,
                  'orderById': 'ASC'}
        if previous_id:
            params['previousId'] = previous_id
        r = requests.get(f'{API}/ledgerreceipts', headers=headers,
                         params=params, timeout=60)
        r.raise_for_status()
        era = r.json()['results']
        if not era:
            return kaikki
        # Hakutulos sisältää perustiedot; kirjanpitorivit haetaan erikseen.
        ids = ','.join(str(x['id']) for x in era)
        details = requests.get(f'{API}/ledgerreceipts/{ids}', headers=headers,
                               timeout=60)
        details.raise_for_status()
        payload = details.json()
        kaikki.extend(payload if isinstance(payload, list) else [payload])
        next_id = era[-1]['id']
        if next_id == previous_id:
            raise RuntimeError('Sivutus ei edennyt')
        previous_id = next_id

Selvittäkää tuotantokäytön hyväksyntä, mahdollinen sertifiointi ja kaupalliset ehdot Procountorin kanssa käyttötapauksen mukaan. Omaan raportointiin tehtävä toteutus ja asiakkaille tarjottava integraatiotuote voivat edellyttää eri valmisteluja.

Rajapinnan käyttöön ja kirjoitettaviin tositteisiin voi liittyä maksuja. Raportointitoteutuksessa riittävät yleensä lukutoiminnot; mahdolliset kirjoitukset suunnitellaan ja hyväksytään erikseen.

Valmis rajapintaraportti vai oma raporttimalli?

Procountorin rajapinnasta saa myös valmiita kirjanpitoraportteja, kuten tuloslaskelman, taseen ja kassavirtalaskelman. Tarkista ensin, riittävätkö ne. Jos johdon raportti vaatii oman jaottelun tai tietojen yhdistämistä, rakenna se vientiriveistä ja erikseen määritellystä raporttimallista. Fennoan Accounting API tarjoaa muun muassa pääkirjan ja tilisaldot.

Kun valmis lähderaportti ei riitä, yhteinen raporttimalli tekee tilien kohdistuksista näkyviä ja ylläpidettäviä. Näin sama laskentasääntö voidaan käyttää eri yhtiöiden tai vastuualueiden raporteissa sovituin poikkeuksin.

Rakenne on sama kuin missä tahansa datamallinnuksessa: raakavientirivit omaan kerrokseensa sellaisenaan, jaottelu ja liiketoimintalogiikka omaansa, ja raportointitaulu valmiiksi laskettuna päälle. Data Studio tai mikä tahansa raportointityökalu lukee vain viimeistä kerrosta.

• Raportin mittarien määrittely ja muutosten hallinta

Tilikartta on se, mikä ratkaisee raportin

Tilien kohdistus raporttiriveille toteutetaan esimerkiksi mappaustaululla. Sen muutokset ja hyväksyjä tulee pystyä jäljittämään, koska kohdistus vaikuttaa raportin lukuihin. Versionhallittu tiedosto tai muutokset tallentava hallintaratkaisu auttaa ylläpidossa.

Suomalaisessa tilikartassa tilit on useimmiten numeroitu niin, että väli vastaa raporttiriviä. Se tekee mappauksesta lyhyen, mutta myös hauraan: yksi päällekkäinen väli tuottaa saman viennin kahdesti, ja yksi puuttuva väli pudottaa vientejä pois hiljaa.

-- Etumerkki käännetään kerran täällä, ei raportilla:
-- tuotot ovat pääkirjassa kredit-puolella eli negatiivisia.
select
  k.raporttirivi,
  k.jarjestys,
  date_trunc(v.tositepvm, month)                 as kausi,
  coalesce(v.kustannuspaikka, 'Kohdistamaton')   as kustannuspaikka,
  sum(v.summa * k.etumerkki)                     as summa
from `talous.stg_paakirja` v
join `talous.dim_tilikartta` k
  on v.tili between k.tili_alku and k.tili_loppu
group by k.raporttirivi, k.jarjestys, kausi, kustannuspaikka
order by kausi, k.jarjestys

Testaa, että jokainen mukaan kuuluva vientirivi osuu täsmälleen yhteen tilikartan väliin. Täsmäytä summat ennen etumerkkimuunnosta tai samalla muunnoksella molemmilla puolilla. Pelkkä kokonaisnettosumma ei riitä: puuttuva debet–kredit-pari voi kumoutua, vaikka rivejä puuttuu.

Näyttäkää kohdistamattomat tilit ja puuttuvat kustannuspaikat raportilla tai erillisessä poikkeamanäkymässä. Sopikaa, kuka selvittää ne ja missä tilanteessa puute estää raportin julkaisun.

Kustannuspaikat ja muut dimensiot

Kustannuspaikat, projektit ja muut dimensiot mahdollistavat raportin erittelyn vastuualueisiin. Tietojen kattavuus voi kuitenkin vaihdella tositelajeittain ja järjestelmien välillä, joten se on tarkistettava lähdeaineistosta.

Ratkaisu ei ole täydentää puuttuvia arvoja arvaamalla, eikä pudottaa rivejä pois. Kumpikin tuottaa raportin, joka on hiljaa väärässä. Näyttäkää puuttuvat omana rivinään, ja sopikaa erikseen kirjaussäännöt niille tositelajeille, joilla dimensio jää tyhjäksi.

Jos dimensioita on useita, kannattaa varautua siihen että niiden nimet muuttuvat. Kustannuspaikkoja yhdistetään ja jaetaan organisaatiomuutosten mukana, ja historian vertailukelpoisuus edellyttää että vanha ja uusi tunnetaan. Tämä hoidetaan dimensiotaululla, jossa on voimassaolopäivämäärät, ei sillä, että vanha nimi korvataan uudella.

Kausi ei ole valmis silloin kun se loppuu

Kirjanpidon kaudet voivat muuttua niiden päättymisen jälkeen. Myöhässä saapuva lasku, jaksotus tai korjaus voi muuttaa aikaisemmin raportoitua tulosta. Raportoinnissa on siksi erotettava uusin tilanne ja mahdollinen aiemmin hyväksytty raporttiversio.

Päivitysmalli valitaan aineiston ja lähteen ominaisuuksien perusteella. Pienessä kokonaisuudessa koko historian haku voi olla yksinkertainen ratkaisu. Suuremmassa voidaan päivittää avoimia kausia ja tunnistettuja muutoksia sekä ajaa tarvittaessa historian korjaukset erikseen.

Kauden lukitustieto auttaa rajaamaan päivityksiä, mutta myös lukituksen purkaminen on huomioitava. Säilyttäkää tarvittaessa julkaistut tilannekuvat, jotta voidaan myöhemmin selvittää, mitä raportilla tiettynä päivänä esitettiin.

• Näytä kauden tila ja raportin päivitysajankohta.
• Täsmäytä julkaistavat luvut lähdejärjestelmään sovituilla rajauksilla.
• Dokumentoi muutokset ja säilytä tarvittavat raporttiversiot.
• Selvitä poikkeamassa sekä kirjanpidon muutokset että tiedonsiirron ja laskennan toiminta.

Budjetti, toteuma ja ennuste samassa taulussa

Budjetti voidaan ylläpitää talousjärjestelmässä tai taulukkolaskennassa. Tärkeää on hallittu rakenne, hyväksytty versio ja selkeä päivitysvastuu. Pienessä raportissa suora taulukkoliitäntä voi riittää; useiden lähteiden ja versioiden hallinnassa tietovarasto voi helpottaa ylläpitoa.

Toimiva ratkaisu on ottaa budjetti Sheetsistä sovitussa muodossa datavarastoon ja yhdistää se toteumaan siellä. Fennoassa budjetit voi myös lukea ja kirjoittaa rajapinnan kautta, jolloin ne saa samasta lähteestä kuin toteuman. Se on siistimpi ratkaisu silloin kun budjetti muutenkin ylläpidetään järjestelmässä.

Tärkein yksityiskohta on tarkkuustaso. Budjetti tehdään usein karkeammalla tasolla kuin toteuma kertyy: budjetti kustannuspaikalle ja kuukaudelle, toteuma tilille ja päivälle. Yhdistäminen tehdään sillä tasolla, jolla molemmat ovat olemassa, ei sillä, jolla toteuma sattuu olemaan tarkin. Muuten budjettiluku monistuu jokaiselle toteumariville ja summa on moninkertainen.

Säilyttäkää tarvittavat ennusteversiot päivämäärällä ja hyväksymistiedolla. Näin ennusteen tarkkuutta voidaan arvioida myöhemmin ja erottaa toisistaan eri ajankohtina tehdyt arviot.

Mitä kuukausiraportilla kannattaa näyttää

Kuukausiraportin rakenne sovitetaan organisaation päätöksiin. Yleiskuvan rinnalle voidaan tarjota porautuminen eriin, jotka tarvitsevat lisäselvitystä.

• Ylärivi: liikevaihto, käyttökate, tulos ja kassa, kukin kauden luku ja ero budjettiin.
• Tuloslaskelma raporttiriveittäin: kausi, kumulatiivinen toteuma, budjetti sekä euromääräinen ja suhteellinen ero.
• Olennaiset poikkeamat budjettiin ja niiden selitykset.
• Kehitys kuukausittain 13 kuukauden ikkunassa, jotta edellinen vuosi on samassa kuvassa.
• Kustannuspaikkataulukko, jos organisaatiossa on useampi vastuualue.
• Merkintä kauden tilasta ja päivitysajankohdasta. Pieni teksti, iso vaikutus luottamukseen.

Mitä tähän ei kuulu: tilikohtainen erittely, tositelistat ja kaikki mikä vaatii selityksen. Ne ovat porautumisnäkymiä, ja ne kannattaa rakentaa, mutta omalle sivulleen, ei johdon näkymään.

Ajastus, laadun tarkistukset ja häiriöiden valvonta

Automatisoitu raportti on tuotantojärjestelmä, vaikka se ei siltä tunnu. Sillä on samat vaatimukset kuin millä tahansa ajolla: se ajetaan säännöllisesti, se epäonnistuu joskus, ja epäonnistumisen pitää tulla jonkun tietoon ennen kuin raporttia luetaan.

Päivitystiheys määräytyy käytön mukaan. Kuukausiraportoinnissa vuorokausittainen ajo voi riittää, kun taas kassaseuranta tai operatiivinen näkymä voi tarvita tiheämpiä päivityksiä. Ajotiheys sovitetaan myös lähteen päivitysrytmiin ja rajapintarajoihin.

Olennaisempaa kuin ajastus on se, että virheellinen ajo ei tuota puolivalmista raporttia. Kirjoita raportointitaulu vasta kun kaikki tarkistukset ovat menneet läpi. Muuten ensimmäinen tieto ongelmasta tulee talouspäälliköltä, joka huomasi että liikevaihto puuttuu.

• Sovittu ajastus ja hallittu mahdollisuus käynnistää korjausajo.
• Tarkistukset ennen julkaisua: rivimäärä järkevällä välillä, mapattujen summa vastaa pääkirjaa, kausi ei ole tyhjä.
• Hälytys, joka menee ihmiselle eikä lokitiedostoon. Epäonnistunut ajo, josta kukaan ei tiedä, on sama kuin ei ajoa.
• Vanhan raportin säilyttäminen näkyvissä epäonnistuneen ajon jälkeen: vanha luku päivitysleimoineen on parempi kuin tyhjä sivu.
• Rajapintakutsut uudelleenyrityksellä. Molemmat järjestelmät ovat välillä poissa, eikä se saa olla syy siihen ettei raporttia ole.

Käyttöoikeudet: talousdata ei ole kuin muu data

Kuukausiraportti sisältää tietoa, jota kaikkien ei kuulu nähdä. Kustannuspaikkatason kuluista voi pienessä organisaatiossa päätellä yksittäisen ihmisen palkan, ja katetiedot ovat liikesalaisuutta. Tämä kannattaa ratkaista ennen ensimmäistä jakelua eikä sen jälkeen.

Data Studion omistajan tunnistetiedoilla katsoja voi nähdä raportin datan ilman omia lähdejärjestelmän oikeuksia. Katsojan tunnistetiedot tai erikseen toteutettu rivisuodatus voivat rajata pääsyä. Testaa valittu malli kunkin vastaanottajaryhmän oikeuksilla, myös ajastetuissa jakeluissa.

Käyttöoikeudet voidaan toteuttaa erillisillä raportointitauluilla, suojatuilla näkymillä tai rivi- ja sarakekohtaisilla säännöillä. Valitkaa malli, jonka oikeellisuus voidaan testata ja jonka ylläpito sopii organisaation käyttäjähallintaan.

Yleisimmät virheet lyhyesti

• Automatisoinnissa huomioidaan vain tiedon haku, vaikka merkittävä käsityö liittyy laskentaan tai täsmäytykseen.
• Takautuvia kirjauksia ja kausien uudelleenavaamista ei käsitellä päivityksissä.
• Tilien kohdistuksen muutoksia, testejä ja hyväksyntää ei dokumentoida.
• Mappauksen välit menevät päällekkäin, jolloin osa vienneistä lasketaan kahteen kertaan. Summa näyttää uskottavalta eikä kukaan huomaa.
• Puuttuvat kustannuspaikat suodatetaan pois raportilta. Luvut näyttävät siisteiltä ja ovat väärin.
• Budjetti liitetään toteumaan väärällä tarkkuustasolla, jolloin budjettiluku monistuu ja ero näyttää järjettömältä.
• Raportilla ei näy päivitysaikaa eikä kauden tilaa, joten jokainen muuttunut luku johtaa selvityspyyntöön.
• Ajo epäonnistuu hiljaa ja raportti jää vanhaksi. Ensimmäinen tieto asiasta tulee siltä, joka ehti tehdä päätöksen vanhalla luvulla.
• API-tunnuksia säilytetään sähköpostissa tai koodissa hallitun salaisuuksien säilytyksen sijaan.
• Projekti aikataulutetaan olettaen, että rajapintatunnukset saadaan samana päivänä kun niitä pyydetään.