Kun käyttäjäsi alkavat pyytää sähköistä laskutusta, tuotteesi tarvitsee neljä ominaisuutta: eurooppalaisen standardin EN 16931 mukaisten laskujen tuottamisen, niiden toimittamisen ostajien käyttämän verkon kautta (Euroopassa pääasiassa Peppol), asiakirjojen validointi ennen niiden lähettämistä ja valinnaisesti asiakirjojen vastaanottaminen käyttäjillesi. Kysymys ei ole enää "onko": Virossa standardi EN 16931 on ensisijainen sähköisen laskun muoto 1. heinäkuuta 2025 alkaen Rekisteröityneillä ostajilla on oikeus vaatia sähköisiä laskuja, ja Baltian maiden B2B-mandaatit tulevat voimaan vuoteen 2028 mennessä. Vaihtoehtoja on kaksi: ryhdy itse sertifioiduksi laskutuspisteeksi tai käytä sitä sen API:n kautta.
Mitä itse rakentaminen oikeastaan tarkoittaa?
Sertifioiduksi tukiasemaksi tuleminen on vaatimustenmukaisuusprojekti, ei ominaisuuslippu: OpenPeppol-jäsenyys, sertifiointi, AS4-viestintäinfrastruktuurin ylläpito, SMP:n käyttäminen osallistujien hallintaan ja sääntöjoukkojen päivitysten seuranta verkon julkaisusyklin aikana. Se on oikea tie sähköisen laskutuksen infrastruktuurin kehittämisessä. on tuotteesi. Kun sähköinen laskutus on vain yksi ominaisuus monien joukossa, tämä polku maksaa neljännesvuosittaisen suunnittelun ennen kuin ensimmäinen käyttäjä näkee arvon.
Mitä API:n käyttäminen tarkoittaa?
Integraatioprojekti: sovelluksesi lähettää laskutustiedot POST-testillä sertifioidun toimittajan API:in, saa synkronisen validoinnin ja siihen liittyvät virheet, toimitustilan webhookien kautta ja osallistujien hallinnan API-toimintoina. Akkreditointi, siirto ja sääntöjen ylläpito pysyvät toimittajalla. Aikajana on erilainen maailma – dokumentoidun API:n avulla, ensimmäinen testidokumentti yhden arkipäivän kuluessa on realistinen, ja tuotantovalmiutta mitataan viikoissa. Tekniset tasot (muodot, validointi, tilat) käsitellään kehittäjäoppaissamme verkkolaskujen lähettäminen API:n kautta lahja UBL-laskujen luominen.
Kuinka tehdä päätös: kolme kysymystä
Ensinnäkin: onko verkkolaskutus tuotteesi ydinominaisuus vai tukeva ominaisuus? Ydinominaisuus oikeuttaa infrastruktuurin omistamisen, tuki ei. Toiseksi: kuinka monta markkinaa sinun on katettava? Jokainen maa lisää sääntöjä. Latvian B2B-velvoite laskeutuu vuonna 2028, Liettuan julkinen sektori vastaanottaa tietoa Peppolin kautta: ja API-palveluntarjoaja kattaa tämän monimuotoisuuden puolestasi. Kolmanneksi: kuka on päivystämässä yöllä? Tukiasema on infrastruktuuri, jonka käyttökatkos pysäyttää käyttäjiesi kassavirran; kysy rehellisesti, haluatko sen hakulaitelistallesi.
Palveluntarjoajan tarkistuslista
Sertifioidun tukiaseman tila. Synkroninen validointi strukturoiduilla virheillä. Erillisillä avaimilla varustettu hiekkalaatikko. Allekirjoitetut, idempotentit webhookit. Osallistujien rekisteröinti ja migraatio API-operaatioina tukipyyntöjen sijaan. Ja dokumentaatio, josta kehittäjäsi ei koskaan tarvitse soittaa tukeen: jälkimmäinen ennustaa kaiken muun laadun.
Usein kysytyt kysymykset
Pitääkö SaaS-palvelun rakentaa oma tukiasema sähköisiä laskuja varten?
Ei. Sertifioidun tukiaseman API-kulutus kattaa formaatin, validoinnin, toimituksen ja hyväksynnän – akkreditointi ja kuljetus jäävät palveluntarjoajalle. Maksat omasta infrastruktuuristasi vain, jos sähköinen laskutus on tuotteen ydin.
Kuinka kauan verkkolaskujen lisääminen SaaS-palveluun kestää?
API-pohjainen: ensimmäisen testidokumentin valmistuminen yhden arkipäivän aikana on realistista dokumentoidulle ratkaisulle, tuotanto viikoissa. Oman tukiaseman rakentaminen on neljännesvuosien kokoinen vaatimustenmukaisuusprojekti.
Mitä vaatimustenmukaisuus teknisesti edellyttää?
EN 16931 -standardin mukaiset asiakirjat, toimitus ostajien verkossa (Peppol-sertifioidun tukiaseman kautta), validointi ennen lähetystä ja SMP-rekisteröinti vastaanottoa varten.
Mitä kannattaa tarkistaa API-palveluntarjoajaa valittaessa?
Sertifioitu AP-status, synkroninen validointi, hiekkalaatikko, allekirjoitetut webhookit, osallistujien hallinta API:n kautta ja dokumentaation laatu.