Saksan E-Rechnung-velvoite: rakenteiset laskut omista järjestelmistä 1. tammikuuta 2027 mennessä

Saksalainen yritys, jonka liikevaihto vuonna 2026 ylitti 800 000 euroa, ei 1. tammikuuta 2027 alkaen voi enää lähettää paperi- tai PDF-laskua toiselle saksalaiselle yritykselle. Laskun on oltava rakenteinen verkkolasku: eurooppalaisen EN 16931 -standardin mukaan muodostettu datatiedosto. 1. tammikuuta 2028 alkaen raja poistuu, ja sääntö koskee jokaista yritystä muutamia kapeita poikkeuksia lukuun ottamatta.

Pienelle yritykselle tämä tulee ohjelmistopäivityksenä. Yritykselle, jonka laskut tulevat omasta laskutusjärjestelmästä, toimialapaketista tai viidentoista vuoden aikana räätälöidystä toiminnanohjausjärjestelmästä, se on ohjelmistoprojekti, ja aikaa on jäljellä noin kolmetoista viikkoa. Tämä artikkeli on jälkimmäiselle ryhmälle.

Mitä laki sanoo

Määritelmä on UStG:n 14 §:ssä: lasku, ”die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht”. Formaatin on oltava direktiivin 2014/55/EU mukaisen eurooppalaisen standardin mukainen (käytännössä EN 16931) tai osapuolten sopima, kunhan vaaditut tiedot voidaan poimia oikein ja täydellisinä muotoon, joka on yhteensopiva standardin kanssa. PDF ei kelpaa, vaikka se näyttäisi kuinka siistiltä.

Velvoite koskee toiselle yritykselle tehtäviä suorituksia, kun molemmat osapuolet ovat sijoittautuneet Saksaan. Siirtymäsäännöt ovat UStG:n 27 §:n 38 momentissa:

• Vuosina 2025 ja 2026 tehdyt suoritukset voi yhä laskuttaa paperilla tai asiakkaan suostumuksella muussa sähköisessä muodossa, kunhan lasku lähtee viimeistään 31. joulukuuta 2026.
• Vuonna 2027 tehdyt suoritukset saavat saman helpotuksen 31. joulukuuta 2027 asti, mutta vain, jos laskuttajan kokonaisliikevaihto edellisenä kalenterivuonna oli enintään 800 000 euroa.
• EDI, joka ei täytä standardia, voi jatkua vuonna 2027 tehdyissä suorituksissa asiakkaan suostumuksella yrityksen koosta riippumatta.

Kolme yksityiskohtaa on tärkeämpiä kuin miltä ne näyttävät.

Raja mitataan edellisen vuoden liikevaihdosta. Vuoden 2027 asema riippuu vuoden 2026 luvusta, jota kukaan ei tiedä tarkasti ennen tilinpäätöstä. Jos olet lähelläkään 800 000 euroa, rakenna kuin olisit rajan yläpuolella.

Helpotus päättyy lähetyspäivään. Kirjaimellisesti luettuna ensimmäinen siirtymäsääntö lakkaa kattamasta paperia ja PDF:ää 31. joulukuuta 2026, myös vuonna 2026 tehdyn työn osalta. Jos olet rajan yläpuolella ja laskutat jälkikäteen, tammikuun ensimmäisellä viikolla joulukuun työstä lähtevän laskun on jo oltava rakenteinen. Varmista tämä veroneuvojalta, mutta älä suunnittele käyttöönottoa tammikuun puoliväliin.

Jotkin laskut jäävät soveltamisalan ulkopuolelle: kuluttajalaskut, rajat ylittävät laskut, enintään 250 euron bruttomääräiset vähäisen arvon laskut, laskuina pidettävät liput, Kleinunternehmer-pienyrittäjien laskut sekä UStG:n 4 §:n kohtien 8:sta 29:ään nojalla verovapaat suoritukset.

Emme tiedä yhdestäkään lakiesityksestä, joka siirtäisi näitä päivämääriä. Suunnittele niin kuin ne pitävät.

Vastaanottaminen on ollut pakollista vuodesta 2025. Laskujen antaminen on uutta.

Jo 1. tammikuuta 2025 alkaen jokaisen saksalaisen yrityksen on pitänyt pystyä vastaanottamaan verkkolaskuja. Saksan valtiovarainministeriön verkkolaskutusta koskeva FAQ sanoo suoraan, mitä se vaatii: ”Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” Sähköpostilaatikko riittää.

Huomaa yksi rivi itse 14 §:ssä: kun verkkolaskuvelvoite on voimassa, vastaanottajan suostumusta ei tarvita. Saksalainen yritysasiakas ei voi kieltäytyä rakenteisesta laskustasi.

Laskujen antaminen on eri ongelma. Vastaanotettaessa työkalu lukee jonkun toisen tiedostoa. Laskua annettaessa järjestelmäsi on sen laatija: jos tiedot ovat väärin jo lähteessä, kukaan myöhemmin ketjussa ei voi korjata niitä, ja lasku, joka ei läpäise asiakkaan validointia, jää maksamatta.

Kenelle tämä tulee päivityksenä

Suoraan sanottuna: jos olet pieni yritys ja laskutat DATEVista, lexofficesta, sevDeskistä tai vastaavasta paketista, ohjelmistotoimittaja toimittaa formaatin. Tarkista perustiedot (ALV-tunniste, asiakasosoitteet, pankkitiedot), kytke ominaisuus päälle ja lähetä testilasku. Et tarvitse projektia etkä ohjelmistoyritystä.

Lähes sama pätee valtavirran toiminnanohjausjärjestelmään, joka on yhä lähellä vakioversiota: toimittaja tai kumppani toimittaa tulosteen, ja työ on konfigurointia ja testausta.

Artikkelin loppuosa on yrityksille, joiden laskut tulevat niiden omasta koodista tai koodista, jota kukaan ei enää ylläpidä:

• tilausalustojen, markkinapaikkojen sekä energia- ja vesiyhtiöiden laskutusmoottorit, jotka antavat laskuja ohjelmallisesti suurina määrinä;
• tukkukaupan, rakentamisen, logistiikan tai kenttähuollon toimialaohjelmistot, joiden toimittaja on pieni, hidas tai poistunut markkinoilta;
• toiminnanohjausjärjestelmät, joiden laskutuloste kirjoitettiin vuosia sitten uudelleen räätälöidyiksi tulostusohjelmiksi, raporttipohjiksi tai kuukauden lopun joukkokirjeeksi.

Formaatit: EN 16931, XRechnung ja ZUGFeRD

EN 16931 on eurooppalainen standardi. Se määrittelee laskun semanttisen mallin (kentät, niiden merkityksen, pakolliset kentät ja niiden väliset liiketoimintasäännöt) ja sitoo sen kahteen XML-syntaksiin, UBL 2.1:een ja UN/CEFACT CII:hin.

XRechnung on EN 16931:n päälle rakennettu saksalainen määrittely, jota KoSIT ylläpitää: puhdasta XML:ää kummalla tahansa syntaksilla, viranomaisten edellyttämä ja yhtä pätevä yritysten välillä. KoSITin XRechnung-sivun mukaan versio 3.0 on ollut voimassa 1. helmikuuta 2024 alkaen ja on voimassa vähintään 31. heinäkuuta 2027 asti. Version 4.0 alustava versio julkaistiin syyskuussa 2026, ja lopullista julkaisua odotetaan keväällä 2027. Käyttöönotto tehdään versiolla 3.0, ja päivitys osuu ensimmäiselle vuodelle.

ZUGFeRD on hybridi: PDF/A-3-tiedosto, johon on upotettu CII XML. Ihmiset lukevat PDF:n, koneet XML:n. Ranskassa sama formaatti tunnetaan nimellä Factur-X, ja ne ovat teknisesti identtiset. FeRD julkaisi version 2.5.2 4. elokuuta 2026. ZUGFeRD:stä on profiileja (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), ja ministeriön FAQ hyväksyy ZUGFeRD:n versiosta 2.0.1 alkaen ”mit Ausnahme der Profile MINIMUM und BASIC-WL”.

Hybridilaskussa ratkaisee XML. FAQ kutsuu rakenteista osaa nimellä ”führender Teil”, johtava osa. Jos PDF ja XML ovat ristiriidassa, PDF on väärin.

Useimmille saksalaisille B2B-laskuttajille järkevä oletus on ZUGFeRD EN 16931 -profiililla, jotta asiakkaat, jotka yhä lukevat laskut silmämääräisesti, voivat jatkaa entiseen tapaan, sekä XRechnung viranomaisille ja kaikille, jotka sitä pyytävät. Molempien pitäisi syntyä yhdestä sisäisestä laskuobjektista eikä kahdesta koodipolusta.

Mitä järjestelmässä on muututtava

Laskusta tulee dataa, ei ulkoasua

Monet vanhemmat järjestelmät muodostavat laskun tulostushetkellä: teksti liitetään pohjaan, summat lasketaan raportin sisällä ja ALV-maininta on kovakoodattu kappale. Mikään tästä ei selviä EN 16931:stä. Tarvitaan tallennettu laskuobjekti, jossa on jokainen kenttä ja josta sekä XML että PDF muodostetaan.

Kentät, jotka yleensä puuttuvat tai ovat väärin:

• Osapuolten tiedot. Rakenteiset osoitteet ISO-maakoodeineen sekä ALV-tunniste tai verotunniste. Vapaatekstiset osoitelohkot on pilkottava.
• Toimituspäivä tai palvelujakso datana eikä lauseena laskun otsakkeessa.
• Yksiköt. Jokainen määrä tarvitsee koodin UN/ECE:n suosituksesta 20 (H87 kappaleelle, KGM kilogrammalle, DAY päivälle). ”Stk.” ja ”pauschal” on muunnettava koodeiksi.
• ALV. Jokaisella rivillä on ALV-luokka ja verokanta. Laskussa on yksi ALV-erittely kutakin luokan ja verokannan yhdistelmää kohden, ja summien on täsmättävä tarkasti kahden desimaalin tarkkuudella. Järjestelmät, jotka pyöristävät ALV:n riveittäin, kaatuvat tähän.
• Verottomuus- ja käännetyn verovelvollisuuden maininnat. PDF:n alalaidan lauseesta tulee ALV-luokan koodi ja verottomuuden peruste.
• Maksu. Maksutapa, IBAN ja maksuehdot rakenteisessa muodossa.
• Viitteet. Tilausnumero tai ostajan viite, jota vasten asiakkaan ostoreskontra täsmäyttää. Jos sitä ei ole koskaan tallennettu, aloita sen kerääminen nyt.

Pelkkää tekstiä sisältävät rivit (”toimitus sovitusti”) ovat tavallinen kompastuskivi. Rakenteisessa laskussa rivi on laskutettava rivi, joten tällainen teksti kuuluu huomautukseen.

Korjaukset, hyvityslaskut ja itselaskutus

FAQ on yksiselitteinen: kun verkkolaskuvelvoite on voimassa, myös korjauksen on oltava verkkolasku, jossa käytetään korjauslaskun laskutyyppiä. EN 16931:ssä korjaus viittaa edeltävään laskuun numerolla ja antopäivällä, joten järjestelmän on säilytettävä tämä linkki datana.

Varo sanastoa. Saksan arvonlisäverolaissa ”Gutschrift” on itselaskutuslasku, jonka asiakas antaa ennalta sovitusti (UStG:n 14 §:n 2 momentti). Se, mitä suomeksi kutsuttaisiin hyvityslaskuksi (hinnanalennus tai peruutus), on Saksassa korjaus. Monet järjestelmät käyttävät molempiin samaa asiakirjatyyppiä. Erota ne ennen kenttävastaavuuksien tekemistä, ja jos käytät itselaskutusta toimittajiesi kanssa, käsittele näitä asiakirjoja laskuina, jotka järjestelmäsi antaa.

Loppulasku voi luetella aiemmat osamaksut liitteessä, kunhan rakenteinen osa viittaa siihen; FAQ vahvistaa, että tämä jatkuu myös vuoden 2027 jälkeen.

Validointi ennen kuin mitään lähtee

KoSIT julkaisee avoimen lähdekoodin validaattorin, joka tarkistaa XML:n skeemoja ja Schematron-sääntöjä vasten ja jolla on julkinen konfiguraatio XRechnungille. Se toimii komentoriviltä, HTTP-daemonina tai kirjastona. Sijoita se lähetyspolkuun: jokainen lasku validoidaan ennen lähtöä, ja virhe päätyy jonoon, jonka omistaa nimetty henkilö ja jossa kerrotaan, mikä kenttä rikkoi minkä säännön.

ZUGFeRD-laskussa validoi upotettu XML profiilisi sääntöjä vasten, tarkista PDF/A-3-säiliö erikseen ja varmista, että PDF näyttää samat summat kuin XML.

Välitys

Laki ”sieht keinen bestimmten Weg vor”, kuten FAQ sanoo: se ei määrää mitään kanavaa. Sähköposti, jonka liitteenä on tiedosto, kelpaa. Samoin API, latausportaali, konsernin sisäinen jaettu tallennustila tai (ministeriön oma esimerkki) USB-tikku. Peppolia ei vaadita Saksan kotimaisessa B2B-laskutuksessa.

Tekninen työ on asiakaskohtaista: laskutusosoite, ensisijainen formaatti ja kirjanpito siitä, mitä lähetettiin minne. Epäonnistuneen lähetyksen jälkeinen uusi yritys sisältää saman asiakirjan samalla laskunumerolla. Kaksi numeroa yhdelle suoritukselle on vero-ongelma, ei ohjelmisto-ongelma.

Arkistointi

Vähintään rakenteinen osa on säilytettävä ”unversehrt in seiner ursprünglichen Form”, koskemattomana alkuperäisessä muodossaan, ja UStG:n 14 b § asettaa säilytysajaksi kahdeksan vuotta antovuoden päättymisestä. Tallenna täsmälleen lähettämäsi tavut tiivisteen kanssa. Älä suunnittele laskujen uudelleenmuodostamista tietokannasta myöhemmin: siihen mennessä data ja koodi ovat muuttuneet. Sama koskee vastaanottamiasi verkkolaskuja.

Suunnitelma lokakuusta joulukuuhun 2026

Kolmetoista viikkoa riittää keskittyneeseen toteutukseen, jos lähdedata on kohtuullisessa kunnossa. Se ei riitä laskutusjärjestelmän korvaamiseen.

Viikot 1 ja 2: kartoitus ja päätökset. Listaa jokainen paikka, jossa lasku syntyy, mukaan lukien manuaaliset hyvityslaskut, projektien loppulaskut ja yhden suuren asiakkaan taulukko. Tarkista vuoden 2026 liikevaihto rajaa vasten. Valitse oletusformaatti ja päätä, rakennetaanko generaattori itse vai lähetetäänkö laskutiedot verkkolaskuoperaattorin API:in.

Viikosta 2 viikkoon 4: datan puuteanalyysi. Käy kolmen kuukauden oikeat laskut läpi kenttä kentältä EN 16931:tä vasten. Merkitse, mitä puuttuu, mistä on tehtävä koodi ja mitä lasketaan eri tavalla. Tässä projektin todellinen koko paljastuu.

Viikosta 4 viikkoon 9: rakentaminen. Laskuobjekti, kenttävastaavuudet, XML- ja PDF/A-3-muodostus, validaattori lähetyspolussa, virhejono ja arkisto. Samaan aikaan joku siivoaa perustiedot ja kerää laskutusosoitteet asiakkailta.

Viikosta 9 viikkoon 11: uudelleenajo ja pilotti. Aja viimeisten kolmen kuukauden laskut uuden generaattorin läpi ja validoi jokainen. Pilotoi sitten muutaman halukkaan asiakkaan kanssa ja kysy, lukevatko heidän järjestelmänsä tiedostot.

Viikosta 11 viikkoon 13: jäädytys ja toimintaohje. Jäädytä muutokset joulukuussa. Kirjaa, kuka omistaa virhejonon, miten korjaus annetaan ja mitä tapahtuu, kun asiakas hylkää laskun. Tammikuun laskut joulukuun työstä kuuluvat jo soveltamisalaan.

Tammikuu 2027. Käyttöönotto, ja jonoa seurataan päivittäin ensimmäisen kuunvaihteen ja ensimmäisen ALV-ilmoituksen yli.

Vuoden 2027 aikana. Suunnittele XRechnung 4.0 -päivitys ennen kuin 3.0 lakkaa olemasta voimassa, ja tuo rajan alle jäävät konserniyhtiöt mukaan ennen 1. tammikuuta 2028.

Jos aloitat myöhään, karsi automaatiosta, älä tulosteen pätevyydestä: automatisoi suurivolyymiset laskutyypit ensin ja lähetä harvinaiset asiakirjat muutaman viikon ajan käsin verkkolaskutyökalun kautta.

Mistä saat apua

Rakennamme yhteyden laskusi tuottavan järjestelmän ja lain vaatiman formaatin välille: tietomallin muutokset, kenttävastaavuudet, validoinnin, välityksen ja arkiston, omassa koodikannassasi ja tiimisi rinnalla. Verkkolaskuintegraatiopalvelumme kuvaa, miten nämä projektit etenevät; jos velvoite osuu keskelle toiminnanohjausjärjestelmän vaihtoa, katso toiminnanohjausjärjestelmän modernisointi. Laajempi kalenteri on oppaassamme EU:n digitaaliseen sääntelyyn 2026.

Olemme insinöörejä emmekä veroneuvojia: soveltamisalaa koskevat kysymykset kuuluvat veroneuvojallesi (Steuerberater), ja me rakennamme sen vastauksen mukaan. Kerro, mikä laskusi tänään tuottaa ja suunnilleen kuinka monta laskua lähtee kuukaudessa: kirjoita osoitteeseen office@c9group.dev.