Verkkolaskutuksen integraatiot: Peppol, XRechnung, ZUGFeRD ja Factur-X järjestelmiin, joita ei niitä varten rakennettu

Verkkolaskutustuotteen ostaminen on helppoa. Ongelma ei juuri koskaan ole tuote, vaan kaksitoista vuotta vanha tilaustenkäsittelyjärjestelmä, joka laskunne muodostaa, hinnoittelulogiikka, jota kukaan ei ole dokumentoinut, ja se tosiasia, että laskunumeronne tulevat tallennetusta proseduurista, jonka kirjoittaja lähti talosta vuonna 2019.

Me rakennamme yhdyskappaleen sen väliin, mitä te todellisuudessa ajatte, ja sen, mitä velvoite vaatii. Rakenteisen laskun muodostus, validointi, verkkosiirto, ostolaskujen vastaanotto ja arkistointi: kytkettynä nykyiseen järjestelmäänne sen sijaan, että se korvattaisiin.

Velvoitteet ja milloin ne purevat

Eurooppa siirtyy PDF-laskuista rakenteisiin, koneluettaviin laskuihin maa kerrallaan, ennen kuin EU:n VAT in the Digital Age (ViDA) -paketti yhtenäistää kokonaisuuden. Päivämäärät, jotka tällä hetkellä käynnistävät projekteja:

• Saksa: rakenteisten verkkolaskujen vastaanotto on ollut pakollista 1. tammikuuta 2025 alkaen. Lähettäminen tulee pakolliseksi 1. tammikuuta 2027 yrityksille, joiden liikevaihto ylittää 800 000 euroa, ja 1. tammikuuta 2028 kaikille muille. Käytännön formaatit ovat XRechnung (puhdas XML) ja ZUGFeRD 2.x (hybridi-PDF, jonka sisään XML on upotettu), molemmat EN 16931 -yhteensopivia.
• Ranska: vastaanotto sekä suurten ja keskisuurten yritysten lähettäminen 1. syyskuuta 2026 alkaen, pk-yritysten lähettäminen 1. syyskuuta 2027 alkaen. Siirto kulkee rekisteröityjen alustojen kautta, ja yleinen hybridiformaatti on Factur-X.
• Belgia: pakollinen B2B-verkkolaskutus Peppolin kautta 1. tammikuuta 2026 alkaen, ja viiden kulman malliin perustuva e-raportointi on suunniteltu vuodelle 2028.
• Puola: KSeF, kansallinen clearance-alusta, omalla XML-skeemallaan ja omalla aikataulullaan.
• Italia: SdI ja FatturaPA, käytössä vuodesta 2019 ja edelleen EU:n tiukin clearance-malli.
• Espanja: Verifactu ja Crea y Crece -lain laskutusvelvoitteet, jotka etenevät alueellisten TicketBAI-järjestelmien rinnalla.

Jos myytte useaan näistä maista, edessänne ei ole yksi projekti. Edessänne on yksi arkkitehtuuri ja useita maakohtaisia sovittimia, ja ero näiden kahden ajattelutavan välillä on ero yhden ja viiden integraation välillä.

Missä projektit todellisuudessa kaatuvat

Laskudataa ei ole siinä muodossa, jota standardi odottaa. EN 16931 vaatii kenttiä, joita moni järjestelmä ei ole koskaan kerännyt: kunnollisen ostajan viitteen, arvonlisäveroerittelyn verokannoittain rivikohtaisen sijaan, rakenteiset maksuehdot ja yksikkökoodit hallitusta koodistosta. Insinöörityö on näiden kenttien johtaminen olemassa olevasta deterministisesti: jokaiselle laskulle, jonka tulette koskaan lähettämään.

Validointivirheet tulevat esiin jälkikäteen. Hylätty lasku on maksamaton lasku. Validoinnin on tapahduttava ennen lähetystä, voimassa olevaa skeemaa ja voimassa olevia maakohtaisia liiketoimintasääntöjä vasten, ja virheet on nostettava ihmisen eteen, joka voi tehdä niille jotain, ei kirjattava lokitiedostoon.

Vastaanotto on vaikeampi kuin lähetys. Kaikki suunnittelevat laskujen lähettämistä ja unohtavat, että vastaanottovelvoitteen alkamispäivästä lähtien on otettava vastaan rakenteisia laskuja jokaiselta toimittajalta missä tahansa standardinmukaisessa formaatissa ja saatava ne ostoreskontraan ilman että joku avaa jokaisen erikseen.

Numerointi ja idempotenssi. Uudelleenyritykset, aikakatkaisut ja alustojen katkokset ovat arkea. Kahdesti kahdella eri numerolla lähetetty lasku on verotuksellinen ongelma, ei ohjelmisto-ongelma. Tämän on oltava kunnossa heti alusta.

Mitä rakennamme

Kartoitus ja formaattipäätös

Lyhyt vaihe, tavallisesti yhdestä kahteen viikkoa, jossa katsomme, miten laskunne todellisuudessa syntyvät, mitkä velvoitteet teitä koskevat ja milloin, ja mitkä ovat realistiset vaihtoehtonne. Tuloksena on kirjallinen suositus: mitä formaatteja tarvitsette, kannattaako Peppol-yhteys hoitaa palveluntarjoajan kautta vai omalla liityntäpisteellä, mitä lähdejärjestelmässä on muututtava ja mitä se maksaa.

Toisinaan suositus on, että vakiotuote ja pieni sovitin riittävät. Sanomme sen mieluummin ensimmäisellä viikolla kuin laskutamme siitä puoli vuotta.

Laskun muodostus ja kenttäkuvaukset

Rakennamme kuvauskerroksen lähdedatastanne vaadittuihin syntakseihin (UBL ja CII EN 16931:n mukaan, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF-XML), ja dokumentoimme kenttien johtamissäännöt niin, että sekä tilintarkastaja että taloushallintonne pysyvät niissä mukana. Jos lähdejärjestelmä ei pysty tuottamaan jotain pakollista kenttää lainkaan, sanomme sen ajoissa ja suunnittelemme tiedon keräämisen sen sijaan, että keksisimme oletusarvon.

Validointi ennen lähetystä

Skeemavalidointi, Schematron-liiketoimintasäännöt ja maakohtaiset tarkistukset ajetaan ennen kuin mitään lähtee talosta. Virheet ohjautuvat jonoon, jolla on ihmisomistaja, ja viestissä lukee mikä kenttä meni pieleen ja miksi, ei stack trace.

Verkkoyhteys

Peppol-liityntäpisteen käyttö joko vakiintuneen palveluntarjoajan kautta tai omana liityntäpisteenä sen mukaan, mikä on volyyminne ja kuinka paljon kontrollia tarvitsette. Clearance-mallin maissa integroimme suoraan kansalliseen alustaan (KSeF, SdI, Ranskan PDP-ekosysteemi), mukaan lukien varmenne- ja tunnistautumiskäsittely, jonka jokainen näistä alustoista tekee omalla tavallaan.

Ostolaskujen vastaanotto

Toimittajalaskujen vastaanotto, validointi ja normalisointi yhteen sisäiseen esitysmuotoon, täsmäytys ostotilauksiin ja vastaanottomerkintöihin siellä missä niitä on, ja toimitus ostolaskujen käsittelyprosessiinne. Tästä projektin tuotto yleensä tulee, koska se poistaa manuaalista näppäilyä, jota kukaan ei ole koskaan mitannut.

Arkistointi ja kirjausketju

Alkuperäisen rakenteisen dokumentin vaatimustenmukainen säilytys siinä muodossa ja sen ajan, jota Saksan GoBD, Italian conservazione sostitutiva tai toiminta-alueenne vastaavat säännöt edellyttävät, ja haun toimivuus testattuna eikä oletettuna.

Järjestelmät, joihin integroimme

SAP ECC ja S/4HANA, Microsoft Dynamics 365 ja Business Central, Odoo, NetSuite, Sage, Infor, Xero, DATEV-rajapinnat ja (useimmin) räätälöity tai raskaasti muokattu järjestelmä, joka on liiketoiminnan ytimessä eikä ole tulossa vaihdetuksi yhden velvoitteen takia. Työskentelemme .NETillä, Javalla, PHP:llä, Pythonilla ja Node.js:llä sekä vanhemmilla pinoilla silloin, kun edessä on sellainen.

Jos ajatte markkinapaikkaa, tilauspohjaista palvelua tai laskutusmoottoria, joka muodostaa laskut ohjelmallisesti isolla volyymilla, olette juuri se tapaus, jota varten meidät on rakennettu: lasku syntyy teidän koodissanne, joten vaatimustenmukaisuuden on asuttava teidän koodissanne.

Mitä emme tee

Emme myy laskutusohjelmistoa emmekä ole taloushallinnon ohjelmistotalo. Jos olette pieni yritys ja etsitte työkalua, joka tuottaa vaatimustenmukaisia laskuja, ostakaa sellainen: DATEV, sevDesk, Lexware ja tusina muuta tekevät tämän hyvin ja murto-osalla integraatioprojektin hinnasta.

Tulkaa meille silloin, kun laskun muodostaa järjestelmä, joka teillä jo on, kun useiden maiden säännöt on saatava elämään rinnakkain tai kun volyymi tarkoittaa, että tämän on toimittava ilman että kukaan katsoo perään.

Miten toimeksianto etenee

Kartoitus, yhdestä kahteen viikkoa, kiinteä hinta, päättyy kirjalliseen suositukseen ja hinnoiteltuun suunnitelmaan.

Toteutus, ensimmäisen maan osalta tyypillisesti kuudesta kahteentoista viikkoa sen mukaan, kuinka siistiä lähdedata on. Työskentelemme teidän repositoriossanne, teidän haaroitusmallillanne ja teidän tiiminne kanssa, ja jätämme jälkeemme testit.

Pilotti, jossa oikeita laskuja ajetaan pienelle joukolle vastapuolia nykyisen prosessin rinnalla, kunnes virheprosentti on siellä missä sen kuuluu olla.

Käyttöönotto ja tuki, virhejono valvottuna ja joku siitä vastuussa, ensimmäisen kuukausisulun ja ensimmäisen arvonlisäveroilmoituksen yli: silloin nimittäin nousevat esiin ne kysymykset, joilla on merkitystä.

Standardit, joiden mukaan työskentelemme

EN 16931 ja sen syntaksisidonnat (UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0 ja Peppolin siirtoinfrastruktuuri, XRechnung ja KoSIT-validaattori, ZUGFeRD 2.x ja Factur-X -profiilit, FatturaPA, KSeF sekä ViDA-ehdotukset, jotka muovaavat vuoden 2030 jälkeistä aikaa.

Usein kysytyt kysymykset

Milloin Saksan verkkolaskuvelvoite tarkalleen koskee meitä?

Vastaanotto on koskenut kaikkia saksalaisia yrityksiä 1. tammikuuta 2025 alkaen. Lähettäminen koskee teitä 1. tammikuuta 2027 alkaen, jos edellisen vuoden liikevaihtonne ylitti 800 000 euroa, ja muussa tapauksessa 1. tammikuuta 2028 alkaen. Velvoite kattaa kotimaiset B2B-liiketoimet; rajat ylittävän laskutuksen ja B2C-laskutuksen käsittely poikkeaa tästä ja kannattaa varmistaa veroasiantuntijaltanne.

Mitä eroa on XRechnungilla ja ZUGFeRDillä?

XRechnung on puhdasta XML:ää, jonka Saksan julkinen sektori on määritellyt ja joka on pakollinen viranomaisille lähetettävissä laskuissa. ZUGFeRD 2.x on hybridi: PDF/A-3-dokumentti, jonka sisään sama rakenteinen data on upotettu, jolloin ihminen lukee PDF:n ja kone XML:n. Molemmat ovat EN 16931 -yhteensopivia. Saksan kaupallisessa B2B-käytännössä ZUGFeRD on yleisempi, ja moni ostaja hyväksyy kumman tahansa.

Tarvitsemmeko oman Peppol-liityntäpisteen?

Yleensä emme. Useimmat yritykset liittyvät olemassa olevan liityntäpistepalvelun kautta, mikä on halvempaa ja nopeampaa. Oma liityntäpiste kannattaa suurilla volyymeilla, kun tarvitsette kontrollia siirtokerrokseen tai kun tarjoatte laskutuspalveluita muille.

Voitteko työskennellä nykyisen verkkolaskutoimittajamme kanssa?

Kyllä, ja usein se on oikea asetelma: toimittaja hoitaa siirron ja verkkojäsenyyden, ja me rakennamme kaiken teidän järjestelmänne ja heidän rajapintansa väliin, kenttäkuvaukset, validoinnin, uudelleenyritykset, virheenkäsittelyn ja täsmäytyksen.

Mitä tapahtuu laskuille, jotka eivät läpäise validointia?

Ne menevät jonoon, jossa on luettava selitys siitä, mikä kenttä rikkoi minkä säännön. Suunnittelemme sen jonon tarkoituksella, koska käyttöönoton jälkeisinä ensimmäisinä kuukausina se on järjestelmän käytetyin osa, ja huono jono muuttaa vaatimustenmukaisuusprojektin pysyväksi käsityöksi.

Miten estätte saman laskun lähettämisen kahdesti?

Vakaalla idempotenssiavaimella, joka johdetaan laskun identiteetistä ja kulkee mukana jokaisessa uudelleenyrityksessä, sekä lähetyslokilla, joka on ainoa totuus siitä mitä on lähetetty. Uudelleenyritys käyttää alkuperäistä tunnistetta eikä muodosta uutta.

Näin pääsette alkuun

Kertokaa, mihin maihin laskutatte, suunnilleen kuinka monta laskua kuukaudessa ja mikä ne tuottaa tänään. Me kerromme, mitkä velvoitteet teitä koskevat ja missä järjestyksessä, ja onko kyseessä liitin vai projekti.

Ottakaa yhteyttä ja varatkaa verkkolaskutuksen valmiusarviointi.

Aiheeseen liittyvät palvelut

• EU-markkinoille tulo – kehitys: loput sääntelykokonaisuudesta, kun myydään Eurooppaan
• ERP-modernisointi ja irtautuminen SAP ECC:stä: kun laskutusvelvoite osuu kesken migraation
• Legacy-järjestelmien ylläpito: sille järjestelmälle, joka laskut muodostaa