Peppol-laskujen virheet: 10 syytä ja ratkaisua

Peppol tarjoaa standardoidun infrastruktuurin sähköisten laskujen ja muiden liiketoimintadokumenttien vaihtoon. Standardointi ei kuitenkaan tarkoita, että jokainen tapahtuma sujuisi automaattisesti.

Lasku voi hylätä, koska sen tiedot ovat virheellisiä, vastaanottajaa ei löydy, on käytetty väärää liiketoimintaprosessia tai ostaja hylkää sen toimituksen jälkeen. Yritysympäristöissä syy voi löytyä mistä tahansa ERP-järjestelmän, laskujen kartoituksen, perustietojen, Peppol-hakupalvelujen ja Access Pointin väliltä.

Tässä oppaassa selitetään kymmenen yleistä Peppol-laskutusvirhettä. Jokainen luku alkaa selkokielisellä kuvauksella käytännön ongelmasta, minkä jälkeen käsitellään asiaan liittyviä teknisiä yksityiskohtia yritysten ja ERP-integraatiotiimien näkökulmasta.

Tekninen laajuus: Tarkastettu Peppol- BIS Billing -standardin version 3.0.21 sekä elokuussa 2026 saatavilla olevien OpenPeppol eDelivery -määritysten perusteella. Maakohtaiset vaatimukset ja määritykset muuttuvat jatkuvasti.

Ennen vianetsintää selvitä, missä vika on tapahtunut.

Nämä virheet vaativat erilaisia toimenpiteitä. Muuttamattoman laskun uudelleenlähettäminen ei korjaa virheellisiä tietoja. Laskun muuttaminen ei auta, jos vastaanottajan Peppol-rekisteröinti on puutteellinen. Siirron onnistunut vastaanotto ei tarkoita, että ostaja olisi hyväksynyt laskun.

Peppol ID -tunniste toimii kuten verkko-osoite, mutta pelkkä oikean organisaationumeron syöttäminen ei aina riitä. Tunnisteen on noudatettava oikeaa rakennetta ja vastattava tarkalleen sitä tunnistetta, jolla vastaanottaja on rekisteröity.

Näennäisesti vähäinen ero – kuten väärä etuliite, poistettu alku-nolla tai arvonlisäverotunnuksen käyttö kansallisen yritystunnuksen sijaan – voi estää Peppolia löytämästä vastaanottajaa.

Tallenna Peppol-tunniste hallittuna perustietona eikä vapaana tekstinä. Tunnistejärjestelmä ja arvo tulisi säilyttää erikseen ja tarkistaa ennen laskutusta.

Ennen lähettämistä:

Yritys voi olla mukana Peppol-verkostossa ilman, että se pystyy vastaanottamaan kaikkia Peppol-asiakirjatyyppejä.

Esimerkiksi vastaanottaja voi olla rekisteröity vastaanottamaan tavallisia Peppol- BIS Billing -laskuja, mutta ei tiettyä PINT-laskua, tilausviestiä tai liiketoimintaprosessia. Vastaanottajan tunnus ( Peppol ID ) on kelvollinen, mutta pyydettyä vastaanottokykyä ei ole käytettävissä.

Älä pidä rekisteröintiä ERP-järjestelmässä pelkkänä kyllä-tai-ei-ominaisuutena. Oleellinen kysymys on, voiko vastaanottaja vastaanottaa juuri sen asiakirjatyypin ja liiketoimintaprosessin yhdistelmän, joka lähetetään.

Integraatiosi tulisi:

Vaikka lasku ja Peppol ID olisivatkin oikein, verkko saattaa tilapäisesti etsiä tietoa väärästä paikasta.

Tämä voi tapahtua, kun yritys vaihtaa Peppol-palveluntarjoajaa, kun vanhat reititystiedot jäävät välimuistiin tai kun muutokset ovat vielä leviämässä. Lähettäjä saattaa saada virheilmoituksen, jonka mukaan vastaanottajaa ei ole olemassa, vaikka todellinen ongelma liittyykin vanhentuneisiin hakutietoihin.

ERP-sovellusten ei tulisi yrittää toteuttaa koko Peppol-hakuprosessia itse, ellei se ole tarkoituksellisesti osa tuotteen arkkitehtuuria. Hakua, varmenteiden vahvistamista, reititystä ja uudelleenkokeilujen käsittelyä hoitaa yleensä paremmin Peppol-palveluntarjoaja.

ERP- ja yritystiimien tulisi edelleen varmistaa, että:

Jokaisessa Peppol-laskussa ilmoitetaan, mitä sääntöjä se noudattaa ja mihin liiketoimintaprosessiin se kuuluu. Jos nämä tunnisteet puuttuvat tai ovat virheellisiä, vastaanottava järjestelmä ei voi tulkita asiakirjaa luotettavasti.

Tämä tapahtuu usein, kun ERP-järjestelmä vie vanhan laskumallin, muunnin syöttää väärän arvon tai kun yhdelle maalle tai prosessille suunniteltu kartoitus otetaan uudelleen käyttöön muualla.

Profiili- ja spesifikaatiotunnisteita tulisi hallita keskitetysti. Käyttäjien ei tulisi voida muokata niitä, eikä niitä tulisi jouduttava luomaan erikseen jokaisessa ERP-liitännässä.

Monimarkkinaympäristöissä:

Laskussa on oltava tiedot, joista ostaja voi selvittää, kuka on tilannut tavarat tai mihin ostotilaukseen lasku liittyy.

Ilman tätä viitettä ostaja ei välttämättä tiedä, mihin lasku tulee lähettää. Siksi Peppol edellyttää joko ostajan viitettä tai ostotilauksen viitettä.

”N/A”-merkinnän lisääminen saattaa saada kentän näyttämään täytetyltä, mutta se ei anna ostajalle hyödyllistä tietoa.

Kerää tarvittavat viitetiedot ennen laskun luomista. Älä luota siihen, että myyntisaatavien hallintaosasto korjaa puuttuvat tiedot sen jälkeen, kun laskun käsittely on epäonnistunut.

Skaalautuvan prosessin tulisi:

Laskussa voi olla oikea kokonaissumma, mutta se voi silti hylätä, koska arvonlisäverotiedot eivät ole järkeviä.

Valitun arvonlisäveroluokan, arvonlisäverokannan ja verovapautuksen perusteen on oltava keskenään yhdenmukaisia. Maasta riippuen saatetaan soveltaa myös muita kansallisia vaatimuksia.

Älä pidä arvonlisäveroa muotoilukysymyksenä, jonka laskunmuunnin hoitaa. Veron määrittäminen tulisi suorittaa asianmukaisessa ERP-järjestelmässä tai verohallintojärjestelmässä ennen laskun luomista.

Yrityksen valvontamenettelyjen tulisi kattaa seuraavat seikat:

Rakenteellisesti pätevä lasku ei välttämättä perustu oikeaan verotuskäytäntöön. Epäselvät verotustilanteet tulisi antaa pätevän verotuksen asiantuntijan tarkastettavaksi.

Laskun lukujen summan on täsmättävä määriteltyjen laskentasääntöjen mukaisesti.

Ongelmia syntyy usein silloin, kun ERP-järjestelmä, verolaskentaohjelma ja laskunmuunnin laskevat samat arvot eri tavoin. Yhden sentin ero voi riittää aiheuttamaan vakavan validointivirheen.

Käytä yhtä dokumentoitua laskenta- ja pyöristysmallia koko laskutusprosessin ajan.

Kiinnitä erityistä huomiota seuraaviin seikkoihin:

Tarkista aina lähetystä varten tuotetun lopullisen XML-tiedoston oikeellisuus. Pelkästään lähde-ERP-tietojen tarkistaminen ei riitä havaitsemaan kartoitus- tai muunnoskerroksessa syntyneitä virheitä.

Jäsennelty lasku ei ole paperilaskun digitaalinen versio. Tyhjiä rivejä, visuaalisia erottimia ja mielivaltaista tekstiä ei tule muuntaa laskuriveiksi.

Jokaisella kentällä ja rivillä on määritelty merkitys. Kentän käyttäminen johonkin muuhun tarkoitukseen saattaa välittää tietoja ostajalle, mutta se estää luotettavan automaation.

ERP-vastaavuuksien tulisi perustua merkitykseen eikä ulkoasuun. Tiedot tulisi kohdistaa sen mukaan, mitä ne tarkoittavat, eikä sen mukaan, missä ne näkyvät tulostetussa laskussa.

Yleisiä säätimiä ovat muun muassa:

Peppol-laskuun voidaan liittää PDF-tiedosto tai muu tiedosto, mutta vastaanottajan ei pitäisi joutua avaamaan sitä ymmärtääkseen tai käsitelläkseen tapahtumaa.

Jos tilausnumero, maksutiedot, arvonlisäverotiedot tai rivikuvaukset löytyvät ainoastaan PDF-tiedostosta, ostaja menettää suuren osan siitä automaatiosta, jota jäsennellyn sähköisen laskutuksen on tarkoitus tarjota.

Käsittele liitteitä taustamateriaalina. Tallenna tarvittavat ja toiminnallisesti tärkeät tiedot jäsenneltyihin laskun kenttiin.

Liitteet voivat olla aiheellisia seuraavissa tilanteissa:

Varmista myös tiedostotyypin, tiedostonimen ja koon vaatimukset. Palveluntarjoajat ja vastaanottavat järjestelmät voivat asettaa toiminnallisia rajoituksia, vaikka tiedostotyyppi sinänsä olisikin tuettu.

”Toimitettu” ei tarkoita ”maksuun hyväksytty”.

Peppol voi välittää teknisesti kelvollisen laskun onnistuneesti, mutta ostaja voi silti kyseenalaistaa tai hylätä sen, koska hinta on väärä, ostotilaus ei täsmää, tavaroita ei ole vastaanotettu tai lasku on lähetetty väärälle oikeushenkilölle.

ERP- ja taloushallinnon käyttäjille ei riitä pelkkä ”lähetetty” tai ”epäonnistunut” -tila. Integraation tulisi erottaa toisistaan seuraavat:

Vastausten tulee liittyä alkuperäiseen laskuun, ja ne on esitettävä tavalla, joka mahdollistaa vastuullisen tiimin toimia. Automaattiset uusintayritykset eivät saa aiheuttaa laskujen päällekkäisyyksiä.

Luotettava sähköinen laskutus vaatii muutakin kuin kelvollisen XML-tiedoston luomista. Koko prosessin on katettava seuraavat seikat:

Yritysorganisaatioissa nämä toiminnot tulisi keskittää sen sijaan, että niitä rakennettaisiin uudelleen erikseen jokaisessa ERP-järjestelmässä, tytäryhtiössä tai markkina-alueella.

ERP- ja alustakumppaneiden osalta Peppol-yhteys tulisi tarjota hallinnoituna palveluna, jossa on vakaat sovellusrajapinnat (API:t), selkeät virheluokat ja käytännölliset vastaukset. Käyttäjien ei pitäisi joutua ymmärtämään SMP-tietueita tai Schematron-sääntöjä laskun korjaamiseksi – mutta integraation on käsiteltävä niitä taustalla oikein.

Qvalia tarjoaa kattavan Peppol-yhteyden yrityksille, ERP-järjestelmien toimittajille ja ohjelmistoalustoille sovellusrajapintojen (API) ja tiedostopohjaisten integraatioiden kautta. Alusta hallinnoi jäsenneltyä asiakirjojen vaihtoa, osallistujien tunnistamista, validointia, vastausviestejä, virheiden käsittelyä sekä tapahtumien jäljitettävyyttä.

Tutustu Qvalian Peppol-yhteyspisteeseen.