Eftir Kristijan Sekereš

E-Rechnung í Þýskalandi: að gefa út skipulega reikninga úr eigin kerfum fyrir 1. janúar 2027

Sjóndeildarhringur Frankfurt í ljósaskiptunum, speglaður í ánni Main

Frá 1. janúar 2027 getur þýskt fyrirtæki sem var með yfir 800.000 evra veltu árið 2026 ekki lengur sent öðru þýsku fyrirtæki reikning á pappír eða sem PDF. Reikningurinn verður að vera skipulegur rafrænn reikningur: gagnaskrá byggð samkvæmt Evrópustaðlinum EN 16931. Frá 1. janúar 2028 falla mörkin niður og reglan gildir um öll fyrirtæki, að fáeinum þröngum undantekningum frátöldum.

Hjá litlu fyrirtæki kemur þetta sem hugbúnaðaruppfærsla. Hjá fyrirtæki sem fær reikningana sína úr eigin reikningakerfi, atvinnugreinapakka eða ERP-kerfi sem hefur verið sérsniðið í fimmtán ár er þetta hugbúnaðarverkefni, og um þrettán vikur eru eftir. Þessi grein er fyrir seinni hópinn.

Hvað lögin segja

Skilgreininguna er að finna í § 14 UStG: reikningur „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht“. Sniðið verður að samræmast Evrópustaðlinum samkvæmt tilskipun 2014/55/ESB (í reynd EN 16931), eða vera umsamið milli aðila, að því tilskildu að hægt sé að draga nauðsynleg gögn rétt og að fullu út á form sem samrýmist þeim staðli. PDF-skjal uppfyllir þetta ekki, hversu snyrtilegt sem það lítur út.

Skyldan nær til afhendinga til annars fyrirtækis þar sem báðir aðilar hafa staðfestu í Þýskalandi. Aðlögunarákvæðin eru í § 27 Abs. 38 UStG:

  • Afhendingar á árunum 2025 og 2026 má enn reikningsfæra á pappír, eða á öðru rafrænu sniði ef viðskiptavinurinn samþykkir, svo lengi sem reikningurinn fer út fyrir 31. desember 2026.
  • Afhendingar árið 2027 fá sama svigrúm til 31. desember 2027, en aðeins ef heildarvelta útgefandans á næstliðnu almanaksári var ekki meiri en 800.000 evrur.
  • EDI sem uppfyllir ekki staðalinn má halda áfram fyrir afhendingar árið 2027, með samþykki viðskiptavinarins, óháð stærð fyrirtækisins.

Þrjú smáatriði skipta meira máli en þau virðast gera.

Mörkin miðast við veltu síðasta árs. Staða þín árið 2027 ræðst af tölunni fyrir 2026, sem enginn veit nákvæmlega fyrr en bókunum hefur verið lokað. Ef þú ert einhvers staðar nálægt 800.000 evrum, smíðaðu eins og þú sért yfir mörkunum.

Svigrúmið endar á sendingardegi. Sé fyrsta aðlögunarreglan lesin bókstaflega hættir hún að ná yfir pappír og PDF 31. desember 2026, jafnvel fyrir vinnu sem unnin var árið 2026. Ef þú ert yfir mörkunum og reikningsfærir eftir á þarf reikningurinn sem þú sendir í fyrstu viku janúar fyrir vinnu í desember þegar að vera skipulegur. Fáðu þetta staðfest hjá skattaráðgjafanum þínum, en ekki skipuleggja gangsetningu um miðjan janúar.

Sumir reikningar falla utan gildissviðsins: reikningar til neytenda, reikningar yfir landamæri, smáreikningar upp að 250 evrum brúttó, farmiðar sem teljast reikningar, reikningar frá Kleinunternehmer og afhendingar sem eru undanþegnar samkvæmt § 4 Nr. 8 til 29 UStG.

Okkur er ekki kunnugt um neitt frumvarp sem færir þessar dagsetningar. Skipuleggðu eins og þær standi.

Móttaka hefur gilt síðan 2025. Útgáfa er nýi hlutinn.

Frá 1. janúar 2025 hefur hvert þýskt fyrirtæki þurft að geta tekið við rafrænum reikningum. Algengar spurningar sambandsfjármálaráðuneytisins um rafræna reikninga eru afdráttarlausar um hvað þarf til: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.“ Pósthólf nægir.

Taktu eftir einni línu í sjálfri § 14: þar sem skyldan til rafrænna reikninga gildir þarf ekki samþykki viðtakandans. Þýskur viðskiptavinur í fyrirtækjarekstri getur ekki hafnað skipulega reikningnum þínum.

Útgáfa er annað vandamál. Þegar þú tekur við les eitthvert tól skrá frá öðrum. Þegar þú gefur út er kerfið þitt höfundurinn: ef gögnin eru röng í upprunanum getur enginn síðar í keðjunni lagað þau, og reikningur sem fellur á sannprófun viðskiptavinarins liggur ógreiddur.

Hverjir fá þetta með uppfærslu

Hreint út sagt: ef þú ert lítið fyrirtæki sem gefur út reikninga úr DATEV, lexoffice, sevDesk eða sambærilegum pakka afhendir framleiðandinn sniðið. Farðu yfir grunngögnin (VSK-númer, heimilisföng viðskiptavina, bankaupplýsingar), kveiktu á eiginleikanum og sendu prufureikning. Þú þarft ekkert verkefni og þú þarft ekkert hugbúnaðarfyrirtæki.

Svipað gildir um algengt ERP-kerfi sem er enn nálægt staðaluppsetningu: framleiðandinn eða samstarfsaðilinn þinn útvegar úttakið og vinnan felst í stillingum og prófunum.

Restin af þessari grein er fyrir fyrirtæki sem fá reikningana sína úr kóða sem þau eiga sjálf, eða kóða sem enginn heldur lengur við:

  • reikningavélar í áskriftarkerfum, markaðstorgum og veitum, sem gefa út reikninga sjálfvirkt í miklu magni;
  • atvinnugreinahugbúnað fyrir heildsölu, byggingariðnað, flutninga eða vettvangsþjónustu, þar sem framleiðandinn er lítill, seinn eða horfinn;
  • ERP-kerfi þar sem reikningaúttakið var endurskrifað fyrir árum sem sérsmíðuð prentforrit, skýrslusniðmát eða bréfasamruni í mánaðarlok.

Sniðin: EN 16931, XRechnung og ZUGFeRD

EN 16931 er Evrópustaðallinn. Hann skilgreinir merkingarfræðilegt líkan reiknings (reitina, hvað þeir þýða, hverjir eru skylda og viðskiptareglurnar milli þeirra) og bindur það við tvær XML-málskipanir, UBL 2.1 og UN/CEFACT CII.

XRechnung er þýska forskriftin ofan á EN 16931, sem KoSIT heldur utan um: hreint XML í hvorri málskipaninni sem er, krafist af opinberum aðilum og jafngilt milli fyrirtækja. Samkvæmt XRechnung-síðu KoSIT hefur útgáfa 3.0 verið í gildi frá 1. febrúar 2024 og verður það að minnsta kosti til 31. júlí 2027. Bráðabirgðaútgáfa af 4.0 var birt í september 2026 og búist er við lokaútgáfu vorið 2027. Þú ferð í loftið á 3.0 og uppfærir innan fyrsta ársins.

ZUGFeRD er blendingur: PDF/A-3 skrá með CII XML innbyggðu. Fólk les PDF-skjalið; vélar lesa XML-ið. Í Frakklandi heitir sama snið Factur-X og þau tvö eru tæknilega eins. FeRD birti útgáfu 2.5.2 hinn 4. ágúst 2026. ZUGFeRD er til í nokkrum prófílum (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), og algengar spurningar ráðuneytisins viðurkenna ZUGFeRD frá útgáfu 2.0.1 „mit Ausnahme der Profile MINIMUM und BASIC-WL“.

Í blendingsreikningi er það XML-ið sem gildir. Algengu spurningarnar kalla skipulega hlutann „führender Teil“, ráðandi hlutann. Ef PDF-skjalinu og XML-inu ber ekki saman er PDF-skjalið rangt.

Fyrir flesta þýska útgefendur reikninga milli fyrirtækja er skynsamlegt sjálfgefið val ZUGFeRD í EN 16931 prófílnum, svo viðskiptavinir sem lesa enn reikninga með augunum geti haldið því áfram, ásamt XRechnung fyrir opinbera aðila og hvern þann sem biður um það. Hvort tveggja ætti að koma úr einum innri reikningshlut, ekki tveimur kóðaleiðum.

Hvað þarf að breytast í kerfinu þínu

Reikningurinn verður gögn, ekki útlit

Mörg eldri kerfi búa reikninginn til við prentun: texta skeytt inn í sniðmát, samtölur reiknaðar inni í skýrslunni, athugasemd um virðisaukaskatt sem harðkóðuð málsgrein. Ekkert af þessu lifir EN 16931 af. Þú þarft vistaðan reikningshlut sem geymir hvern reit, og bæði XML og PDF eru birt út frá honum.

Reitirnir sem yfirleitt vantar eða eru rangir:

  • Upplýsingar um aðila. Skipuleg heimilisföng með ISO-landakóðum, og VSK-númer eða skattnúmer. Heimilisfangablokkir í frjálsum texta þarf að brjóta upp.
  • Afhendingardagur eða þjónustutímabil, geymt sem gögn frekar en sem setning í hausnum.
  • Einingar. Hvert magn þarf kóða úr tilmælum UN/ECE nr. 20 (H87 fyrir stykki, KGM fyrir kílógramm, DAY fyrir dag). „Stk.“ og „pauschal“ þarf að varpa.
  • Virðisaukaskattur. Hver lína ber virðisaukaskattsflokk og skatthlutfall. Reikningurinn ber eina sundurliðun virðisaukaskatts fyrir hverja samsetningu flokks og hlutfalls, og samtölurnar verða að ganga nákvæmlega upp í tveimur aukastöfum. Kerfi sem námunda virðisaukaskatt í hverri línu falla hér.
  • Orðalag um undanþágur og öfuga skattskyldu. Setningin neðst á PDF-skjalinu verður kóði virðisaukaskattsflokks ásamt ástæðu undanþágu.
  • Greiðsla. Greiðslumáti, IBAN og skilmálar á skipulegu formi.
  • Tilvísanir. Pöntunarnúmerið eða tilvísun kaupanda sem bókhaldsdeild viðskiptavinarins parar við. Ef þú hefur aldrei geymt hana, byrjaðu að skrá hana núna.

Línur sem eru eingöngu texti („afhending eins og um var samið“) eru algeng hindrun. Í skipulegum reikningi er lína reikningsfærð lína, svo sá texti á heima í athugasemd.

Leiðréttingar, kreditreikningar og self-billing

Algengu spurningarnar eru skýrar: þar sem skyldan til rafrænna reikninga gildir þarf leiðrétting líka að vera rafrænn reikningur, með reikningstegundinni fyrir leiðréttingu. Í EN 16931 vísar hún aftur í fyrri reikninginn með númeri og útgáfudegi, svo kerfið þitt þarf að geyma þá tengingu sem gögn.

Gættu að hugtökunum. Í þýskum virðisaukaskattslögum er „Gutschrift“ reikningur sem viðskiptavinurinn gefur út sjálfur samkvæmt fyrirfram gerðu samkomulagi (§ 14 Abs. 2 UStG), það sem á ensku kallast self-billing. Það sem við köllum kreditreikning (verðlækkun eða ógilding) er leiðrétting. Mörg kerfi nota eina skjalategund fyrir hvort tveggja. Aðskildu þær áður en þú varpar þeim, og ef þú gefur út reikninga fyrir hönd birgja, meðhöndlaðu þau skjöl sem reikninga sem kerfið þitt gefur út.

Lokareikningur má telja upp fyrri hlutagreiðslur í viðhengi, að því tilskildu að skipulegi hlutinn vísi í það; algengu spurningarnar staðfesta að svo verði áfram eftir 2027.

Sannprófun áður en nokkuð fer út

KoSIT birtir opinn sannprófunarhugbúnað sem athugar XML gegn skemum og Schematron-reglum, með opinberri stillingu fyrir XRechnung. Hann keyrir af skipanalínu, sem HTTP-þjónn eða sem safn. Settu hann í sendingarleiðina: hver reikningur er sannprófaður áður en hann fer út, og villa lendir í biðröð sem nafngreind manneskja ber ábyrgð á, með upplýsingum um hvaða reitur braut hvaða reglu.

Fyrir ZUGFeRD skaltu sannprófa innbyggða XML-ið gegn reglum prófílsins, athuga PDF/A-3 umbúðirnar sérstaklega og ganga úr skugga um að PDF-skjalið sýni sömu samtölur og XML-ið.

Sending

Lögin, segja algengu spurningarnar, „sieht keinen bestimmten Weg vor“: þau mæla ekki fyrir um neina sérstaka leið. Tölvupóstur með skrána í viðhengi er í lagi. Sömuleiðis API, niðurhalsgátt, sameiginleg geymsla innan samstæðu eða (dæmi ráðuneytisins sjálfs) USB-lykill. Peppol er ekki skylda í innlendum viðskiptum milli fyrirtækja í Þýskalandi.

Verkfræðivinnan er fyrir hvern viðskiptavin: reikningsfang, valið snið og skrá yfir hvað var sent hvert. Endursending eftir misheppnaða sendingu ber sama skjal með sama reikningsnúmeri. Tvö númer fyrir eina afhendingu er skattavandamál, ekki hugbúnaðarvandamál.

Varðveisla

Að minnsta kosti skipulega hlutann þarf að geyma „unversehrt in seiner ursprünglichen Form“, óskertan í upprunalegri mynd, og § 14b UStG kveður á um átta ára varðveislu frá lokum útgáfuársins. Geymdu nákvæmlega þau bæti sem þú sendir, með tætigildi (hash). Ekki gera ráð fyrir að búa reikningana til aftur úr gagnagrunninum síðar: þá hafa bæði gögnin og kóðinn breyst. Hið sama gildir um rafræna reikninga sem þú tekur við.

Áætlun fyrir október til desember 2026

Þrettán vikur duga fyrir markvissa smíði ef upprunagögnin eru í þokkalegu ástandi. Þær duga ekki til að skipta út reikningakerfinu.

Vikur 1 og 2: úttekt og ákvarðanir. Skráðu hvern einasta stað þar sem reikningur verður til, þar á meðal handgerða kreditreikninga, lokareikninga verkefna og töflureikninn fyrir einn stóran viðskiptavin. Berðu veltu ársins 2026 saman við mörkin. Veldu sjálfgefið snið og ákveddu hvort þú smíðar reikningagerðina sjálfur eða sendir reikningsgögn á API hjá þjónustuaðila fyrir rafræna reikninga.

Vikur 2 til 4: frávikagreining gagna. Varpaðu þriggja mánaða raunverulegum reikningum reit fyrir reit á EN 16931. Merktu hvað vantar, hvað þarf að verða kóði og hvað er reiknað öðruvísi. Hér kemur raunveruleg stærð verkefnisins í ljós.

Vikur 4 til 9: smíði. Reikningshluturinn, vörpunin, framsetning XML og PDF/A-3, sannprófunin í sendingarleiðinni, villubiðröðin og varðveislan. Samhliða hreinsar einhver grunngögnin og aflar reikningsfanga frá viðskiptavinum.

Vikur 9 til 11: endurspilun og prufukeyrsla. Keyrðu reikninga síðustu þriggja mánaða í gegnum nýju reikningagerðina og sannprófaðu hvern einasta. Prufukeyrðu síðan með nokkrum viljugum viðskiptavinum og spurðu hvort kerfin þeirra lesi skrárnar.

Vikur 11 til 13: frysting og verklýsing. Frystu breytingar í desember. Skrifaðu niður hver ber ábyrgð á villubiðröðinni, hvernig leiðrétting er gefin út og hvað gerist þegar viðskiptavinur hafnar reikningi. Janúarreikningar fyrir vinnu í desember falla þegar undir.

Janúar 2027. Farðu í loftið og fylgstu daglega með biðröðinni fram yfir fyrstu mánaðamótin og fyrstu virðisaukaskattsskýrsluna.

Allt árið 2027. Skipuleggðu uppfærsluna í XRechnung 4.0 áður en 3.0 hættir að gilda, og komdu fyrirtækjum í samstæðunni sem eru undir mörkunum yfir fyrir 1. janúar 2028.

Ef þú byrjar seint, skerðu niður sjálfvirknina, ekki gildi úttaksins: gerðu algengustu reikningstegundirnar sjálfvirkar fyrst og sendu sjaldgæf skjöl handvirkt í gegnum tól fyrir rafræna reikninga í nokkrar vikur.

Hvar þú færð aðstoð

Við smíðum tenginguna milli kerfisins sem framleiðir reikningana þína og sniðsins sem lögin krefjast: breytingar á gagnalíkani, vörpun, sannprófun, sendingu og varðveislu, í kóðagrunninum þínum og við hlið teymisins þíns. Þjónusta okkar við samþættingu rafrænna reikninga lýsir því hvernig slík verkefni ganga fyrir sig; ef skyldan lendir í miðjum ERP-skiptum, sjáðu nútímavæðingu ERP-kerfa. Víðara dagatalið er í handbók okkar um stafrænt regluverk ESB 2026.

Við erum verkfræðingar en ekki skattaráðgjafar: spurningar um gildissvið eiga heima hjá Steuerberater ykkar og við smíðum eftir svari hans. Segðu okkur hvað framleiðir reikningana þína í dag og hve margir fara út í hverjum mánuði, gróflega: skrifaðu á office@c9group.dev.