ISO 20022 muuttaa maksujen osoite­tieto­vaatimuksia – ovatko ERP:n tiedot kunnossa?

Maksajan ja maksunsaajan osoitetietoja koskevat vaatimukset ovat muuttumassa eurooppalaisessa SEPA-maksuliikenteessä. Kun yritys maksaa ostolaskunsa ERP- tai taloushallintojärjestelmästä muodostetulla maksuaineistolla, aineistoon siirtyvät myös maksunsaajan osoitetiedot – yleensä suoraan toimittajarekisteristä. Siksi muutos koskee sekä ohjelmistoa että sitä tietoa, joka järjestelmään on vuosien aikana kertynyt.

Mitä ISO 20022 -osoitetietomuutos tarkoittaa?

Muutos tarkoittaa, että maksuaineistossa välitettävissä osoitetiedoissa siirrytään vapaamuotoisista osoiteriveistä rakenteiseen tai hybridimuotoiseen osoitteeseen. Rakenteisessa osoitteessa osoitteen osat annetaan omissa kentissään. Hybridiosoitteessa vähintään maa ja postitoimipaikka ovat rakenteisina tietoina, mutta mukana voi olla myös vapaamuotoisia osoiterivejä.

ISO 20022 on kansainvälinen maksusanomien standardi, jonka varaan myös SEPA-maksujen aineistot rakentuvat. SEPA-maksujärjestelmien sääntöjä ylläpitää European Payments Council (EPC). EPC:n osoitetietoja koskeva ohjeistus (EPC153-22, versio 2.2) tuntee kolme osoitemuotoa:

• Rakenteinen osoite: maa ja postitoimipaikka ovat pakollisia, ja muut osat annetaan omissa kentissään. Vapaamuotoisia osoiterivejä ei käytetä.
• Hybridiosoite: maa ja postitoimipaikka ovat omissa kentissään, ja lisäksi voi olla enintään kaksi vapaamuotoista osoiteriviä.
• Rakenteeton osoite: enintään kaksi vapaamuotoista osoiteriviä. Tästä muodosta ollaan luopumassa.

Käytännössä maksuaineisto muodostetaan usein ERP- tai taloushallintojärjestelmässä ja lähetetään pankille pankkiyhteysohjelmiston tai pankin palvelun kautta. Jos osoitetietoja välitetään maksuaineistossa, ne tulevat tyypillisesti järjestelmän perustiedoista. Kyse ei siis ole yhden ERP-ohjelmiston muutoksesta, vaan maksuliikenteen yhteisestä muutoksesta.

EPC:n ohje koskee sen maksujärjestelmiä, kuten SEPA-tilisiirtoa ja SEPA-pikasiirtoa. Osoitetietojen pakollisuus riippuu maksutyypistä ja maksun osapuolista. Esimerkiksi SCT- ja SCT Inst -maksuissa maksajan osoite on pakollinen, jos maksajan tai maksunsaajan pankki sijaitsee Euroopan talousalueen (ETA) ulkopuolisessa SEPA-maassa. ETA:n sisäisissä SEPA-maksuissa osoitetietoja ei aina vaadita. SEPA-alueen ulkopuolisissa kansainvälisissä maksuissa vaatimukset voivat poiketa EPC:n SEPA-säännöistä. Esimerkiksi Swiftin CBPR+-maksuissa täysin rakenteettomista osoitteista oli alkuperäisen aikataulun mukaan tarkoitus luopua 14.11.2026, minkä jälkeen osoite olisi annettu rakenteisessa tai hybridimuodossa, jossa vähintään postitoimipaikka ja maa ovat omissa kentissään. Swift ilmoitti kuitenkin 27.8.2026 jatkavansa siirtymäaikaa ja kertovansa uudesta aikataulusta viimeistään joulukuussa 2026.

Onko 15.11.2026 edelleen määräpäivä?

Ei. EPC poisti syyskuussa 2026 osoitetietoja koskevasta ohjeestaan päivämäärän 15.11.2026, ja uusi lopullinen määräpäivä ilmoitetaan myöhemmin.

EPC tiedotti lykkäyksestä 10.9.2026, ja ohjeen päivitetty versio 2.2 julkaistiin 30.9.2026. Rakenteettoman osoitteen tuki jatkuu toistaiseksi, ja uusi päättymispäivä päätetään markkinan ja maksuliikennealan kehityksen perusteella. EPC on samalla todennut, että muutoksen suunta ei ole muuttunut, ja suosittelee edelleen siirtymistä suoraan rakenteiseen osoitteeseen. (Tilanne 2.10.2026.)

Käytännössä yrityksellä on nyt enemmän aikaa. Kun uusi päivä aikanaan vahvistetaan, puutteelliset tai standardin vaatimuksia täyttämättömät osoitetiedot voivat johtaa yksittäisen maksun tai koko maksuaineiston hylkäämiseen. Miten pankki tilanteen tarkalleen käsittelee, riippuu pankista.

Lisäaika ei ole syy jättää toimittajarekisteriä tarkistamatta. Se antaa mahdollisuuden tehdä korjaukset rauhassa eikä vasta viime hetkellä.

Mitä yrityksen kannattaa tarkistaa ERP:stä nyt?

Tarkistettavaa on kaksi asiaa: osaako käytössä oleva ohjelmisto muodostaa osoitteen uusien vaatimusten mukaisesti, ja onko maksunsaajien osoitetieto järjestelmässä sellaisessa kunnossa, että ohjelmisto pystyy käyttämään sitä.

1. Selvitä, mistä järjestelmästä maksuaineisto muodostetaan. Se voi olla ERP, erillinen taloushallinnon ohjelmisto tai tilitoimiston järjestelmä. Joissakin yrityksissä lähteitä on useita, esimerkiksi ostolaskut ja palkat eri järjestelmistä.
2. Tarkista ohjelmistotoimittajan ohjeistus ISO 20022 -osoitetiedoista. Mitä ohjelmisto tekee automaattisesti, mitä asiakkaan pitää tehdä itse ja mistä versiosta alkaen.
3. Tarkista toimittaja- ja maksunsaajarekisterin osoitetietojen laatu. Jos osoite välitetään rakenteisena tai hybridimuotoisena, maa ja postitoimipaikka ovat keskeisiä rakenteisia tietoja. Puuttuvat tai väärissä kentissä olevat tiedot kannattaa korjata jo nyt.
4. Kiinnitä erityistä huomiota ulkomaisiin toimittajiin. Ulkomaisten osoitteiden muodot vaihtelevat, eikä niitä voi täydentää suomalaisista rekistereistä.
5. Tarkista, ovatko tiedot oikeissa kentissä. Erityisesti maa ja postitoimipaikka pitää pystyä välittämään niille tarkoitetuissa rakenteisissa kentissä silloin, kun käytetään rakenteista tai hybridiosoitetta.
6. Varmista käytössä olevan ohjelmistoversion valmius. Jos versio on jäänyt jälkeen, päivitys kannattaa suunnitella hyvissä ajoin.
7. Testaa maksuaineisto tarvittaessa ennen kuin muutos tulee voimaan. Pankki tai ohjelmistotoimittaja kertoo, miten testaus onnistuu.

Miksi ohjelmistopäivitys ei yksin riitä?

Koska päivitys muuttaa tapaa, jolla tieto muodostetaan maksuaineistoon – se ei korjaa itse tietoa.

Ohjelmistotoimittaja voi päivittää järjestelmän tukemaan uutta aineistorakennetta. Päivitys ei kuitenkaan automaattisesti tee asiakkaan vuosien aikana kertyneestä perustiedosta laadukasta. Toimittajarekisterissä näkyy tyypillisesti esimerkiksi seuraavia tilanteita:

• maa-kenttä on tyhjä, koska kaikkien on oletettu olevan suomalaisia
• postitoimipaikka puuttuu tai on kirjoitettu katuosoitteen perään
• osoite on vanha, koska toimittajan muutto ei ole koskaan päivittynyt rekisteriin
• ulkomaisen toimittajan koko osoite on yhdellä vapaamuotoisella rivillä
• sama toimittaja on rekisterissä useaan kertaan eri tiedoilla
• tiedot on siirretty vanhasta järjestelmästä vuosia sitten sellaisenaan, ja kenttien käyttötapa on ollut eri kuin nykyisessä järjestelmässä

Mikään näistä ei välttämättä haittaa arjessa, koska maksut ovat tähän asti menneet läpi. Uusien vaatimusten myötä sama tieto voi kuitenkin estää maksun. Siksi perustietojen laatu on tässä muutoksessa vähintään yhtä tärkeä kuin ohjelmistoversio.

Miten Lemonsoft valmistautuu muutokseen?

Lemonsoft on yksi esimerkki siitä, miten ERP-ohjelmiston toimittaja valmistautuu muutokseen: ohjelmistoa kehitetään, ja asiakkaita ohjeistetaan tarkistamaan omat tietonsa. Sama tarkistus koskee yhtä lailla muita järjestelmiä, joista maksuaineisto muodostetaan.

Lemonsoftin virallisen ISO 20022 -ohjeen mukaan toimittajilta kannattaa tarkistaa erityisesti postitoimipaikka ja maa, jotka ovat ehdoton minimivaatimus. Katuosoite ja postinumero kannattaa täydentää samalla. Ohjeen mukaan puutteet koskevat useimmiten ulkomaisia toimittajia.

Lemonsoft muodostaa maksuaineiston osoitteen hybridiosoitteena: postitoimipaikka ja maa rakenteisina ja muu osoite enintään kahdella rivillä. Jos tietoja on vähemmän, käytetään hybridiosoitetta minimivaatimuksilla. LemonOnlinessa ostolaskun hyväksyntä näyttää varoituksen, jos toimittajalta puuttuu postitoimipaikka tai maa.

Lemonsoftin ohjeessa korostetaan myös käyttöympäristöä. Jatkuvan julkaisun piirissä olevat asiakkaat saavat muutoksen normaalin päivityksen mukana, kun taas omalla palvelimella tai vanhemmassa ympäristössä Lemonsoftia käyttävien pitää huolehtia päivityksestä tai siirrosta itse. Ohje on kirjoitettu alkuperäisen 15.11.2026 aikataulun pohjalta, mutta siihen on lisätty maininta määräajan siirtymisestä.

Lemonsoftiin on myös tullut automatisointipalvelu, joka täydentää puuttuvia asiakas- ja toimittajatietoja YTJ:stä. Palvelu hakee aktiivisille, y-tunnuksellisille asiakkaille ja toimittajille tyhjiin kenttiin muun muassa osoitteen, postinumeron, postitoimipaikan ja maan. Se ei korvaa rekisterissä jo olevaa tietoa, eikä se käsittele ulkomaisia tai y-tunnuksettomia toimittajia – niiden tiedot pitää täydentää käsin.

YTJ-täydennys auttaa siis tyhjien kenttien kanssa, mutta ei korjaa vanhentunutta tai väärään kenttään kirjattua tietoa. Lemonsoftin käytön kehittämisestä ja pääkäyttäjätuesta kerrotaan tarkemmin sivulla Lemonsoft Vastuunkantaja.

Muutos kertoo jotain suurempaa ERP:n ylläpidosta

ERP-järjestelmä voi toimia teknisesti moitteetta ja silti jäädä vähitellen jälkeen siitä, mitä yritys ja sen toimintaympäristö vaativat.

ERP:n toimivuus ei riipu vain siitä, että ohjelma käynnistyy ja käyttäjät pystyvät tekemään kirjauksia. Ajan myötä muuttuvat yrityksen prosessit ja liiketoiminnan tarpeet, ohjelmiston ominaisuudet, integraatiot ja raportointi. Samaan aikaan muuttuvat viranomaisvaatimukset, maksuliikenteen standardit ja järjestelmän perustiedot.

Yksikään näistä muutoksista ei yleensä kaada järjestelmää. Yhdessä ne kuitenkin kasautuvat: järjestelmä toimii, mutta palvelee yritystä vähän huonommin vuosi vuodelta. ISO 20022 -osoitetiedot ovat yksi hyvä esimerkki siitä, miten ulkoinen muutos paljastaa perustiedoissa vuosia olleen puutteen.

Kuka huomaa muutokset ennen kuin niistä tulee ongelmia?

Jonkun pitää olla nimetysti vastuussa siitä. Monessa pk-yrityksessä tehtävä jää pääkäyttäjälle tai talousjohdolle muiden töiden ohessa – tai ei kenellekään.

Osaavan ERP-kumppanin arvo ei synny vain siitä, että hän osaa ratkaista käyttäjän ongelman. Arvo syntyy myös siitä, että joku seuraa, mitä järjestelmässä ja sen ympärillä muuttuu, arvioi vaikutukset yritykseen ja huolehtii tarvittavat muutokset käytäntöön.

Käytännössä se tarkoittaa esimerkiksi:

• ohjelmistotoimittajien tiedotteiden ja muutosten seuraamista
• versionhallintaa ja päivitysten suunnittelua
• perustietojen laadun säännöllistä tarkistamista
• uusien ominaisuuksien arviointia yrityksen tarpeiden kannalta
• prosessien kehittämistä ja käyttäjien toimintatapojen yhtenäistämistä
• muutosten testaamista ennen tuotantokäyttöä
• vastuuta siitä, että asiat eivät jää sähköpostin tai tukitiedotteen tasolle

ERP Managers kutsuu tätä roolia yrityksen omaksi ERP-vastuunkantajaksi. Se voi olla oma henkilö tai ulkopuolinen kumppani, mutta tehtävän pitää olla jonkun. Lisää aiheesta sivulla ERP-järjestelmän jatkuva kehittäminen.

Mitä kannattaa tehdä nyt?

Määräpäivän siirtyminen antaa aikaa, mutta tarkistukset kannattaa tehdä nyt:

• tarkista ohjelmistotoimittajan tilanne ja käytössä olevan version valmius
• tarkista toimittajarekisterin osoitetiedot, erityisesti maa ja postitoimipaikka
• korjaa puutteet ja käy ulkomaiset toimittajat läpi erikseen
• määrittele, kuka vastaa jatkossa tämän tyyppisten ERP-muutosten seuraamisesta

Usein kysyttyä ISO 20022 -osoitetiedoista

Koskeeko ISO 20022 -osoitetietomuutos vain Lemonsoftia?

Ei. Muutos liittyy laajemmin ISO 20022 / EPC / SEPA -maksuliikenteeseen. Lemonsoft on tässä artikkelissa yksi ohjelmistokohtainen esimerkki.

Onko 15.11.2026 edelleen muutoksen määräpäivä?

Ei. EPC poisti määräpäivän syyskuussa 2026 ja ilmoittaa uuden päättymispäivän myöhemmin.

Riittääkö ERP-ohjelmiston päivittäminen?

Ei välttämättä. Myös järjestelmässä olevan toimittaja- ja maksunsaajatiedon pitää olla laadukasta ja oikeissa kentissä.

Mitä yrityksen kannattaa tehdä nyt?

Tarkistaa ohjelmistotoimittajan valmius sekä toimittajarekisterin osoitetietojen laatu ja määritellä, kuka vastaa muutoksen etenemisestä.