Obveznost E-Rechnung v Nemčiji: izdajanje strukturiranih računov iz lastnih sistemov do 1. januarja 2027

Od 1. januarja 2027 nemško podjetje, katerega promet je leta 2026 presegel 800.000 €, drugemu nemškemu podjetju ne sme več poslati papirnatega računa ali računa v PDF. Račun mora biti strukturiran e-račun: podatkovna datoteka, izdelana po evropskem standardu EN 16931. Od 1. januarja 2028 prag izgine in pravilo velja za vsa podjetja, razen nekaj ozkih izjem.

Za majhno podjetje to pride kot posodobitev programske opreme. Za podjetje, katerega računi nastajajo v lastnem sistemu za obračun, v panožnem paketu ali v ERP, ki so ga prilagajali petnajst let, je to projekt razvoja programske opreme, do roka pa je ostalo približno trinajst tednov. Ta članek je za drugo skupino.

Kaj pravi zakon

Opredelitev je v § 14 UStG: račun, „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht“, torej račun, ki je izdan, poslan in prejet v strukturirani elektronski obliki in omogoča elektronsko obdelavo. Format mora ustrezati evropskemu standardu po Direktivi 2014/55/EU (v praksi EN 16931) ali pa ga stranki dogovorita med seboj, če je mogoče zahtevane podatke pravilno in v celoti izluščiti v obliko, združljivo s tem standardom. PDF se ne šteje, pa naj bo videti še tako urejen.

Obveznost zajema dobave drugemu podjetju, kadar imata obe strani sedež v Nemčiji. Prehodno obdobje ureja § 27 Abs. 38 UStG:

• Dobave, opravljene v letih 2025 in 2026, se še lahko zaračunajo na papirju ali v drugi elektronski obliki, če se kupec strinja, pod pogojem, da je račun poslan do 31. decembra 2026.
• Dobave, opravljene leta 2027, imajo enako olajšavo do 31. decembra 2027, vendar le, če skupni promet izdajatelja v preteklem koledarskem letu ni presegel 800.000 €.
• EDI, ki ne ustreza standardu, se lahko s soglasjem kupca nadaljuje za dobave, opravljene leta 2027, ne glede na velikost podjetja.

Tri podrobnosti so pomembnejše, kot se zdijo.

Prag se meri na prometu preteklega leta. Vaš položaj v letu 2027 je odvisen od številke za leto 2026, ki je nihče ne bo natančno poznal, dokler se knjige ne zaprejo. Če ste kjer koli blizu 800.000 €, gradite, kot da ste nad pragom.

Olajšava se konča z datumom pošiljanja. Dobesedno brano prvo prehodno pravilo 31. decembra 2026 preneha pokrivati papir in PDF, tudi za delo, opravljeno leta 2026. Če ste nad pragom in zaračunavate za nazaj, mora biti račun, ki ga v prvem tednu januarja pošljete za decembrsko delo, že strukturiran. To preverite s svojim davčnim svetovalcem, vendar začetka ne načrtujte za sredino januarja.

Nekateri računi ostanejo zunaj obsega: računi potrošnikom, čezmejni računi, računi za majhne zneske do 250 € bruto, vozovnice, ki štejejo kot računi, računi oseb, ki so Kleinunternehmer (mali podjetniki), in dobave, oproščene po § 4 Nr. 8 do 29 UStG.

Ne vemo za noben predlog zakona, ki bi te datume premaknil. Načrtujte, kot da veljajo.

Prejemanje velja od leta 2025. Izdajanje je novi del.

Od 1. januarja 2025 mora vsako nemško podjetje znati prejemati e-račune. Pogosta vprašanja zveznega ministrstva za finance o e-računih so glede tega, kaj je za to potrebno, neposredna: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.“ Poštni predal zadošča.

Bodite pozorni na en stavek v samem § 14: kjer velja obveznost e-računa, soglasje prejemnika ni potrebno. Nemška poslovna stranka vašega strukturiranega računa ne more zavrniti.

Izdajanje je drugačna težava. Pri prejemanju orodje bere datoteko nekoga drugega. Pri izdajanju je vaš sistem avtor: če so podatki napačni že na izvoru, jih nihče pozneje v verigi ne more popraviti, račun, ki ne prestane preverjanja pri vaši stranki, pa ostane neplačan.

Kdo to dobi s posodobitvijo

Naravnost povedano: če ste majhno podjetje in račune izdajate v DATEV, lexoffice, sevDesk ali podobnem paketu, format dobavi vaš ponudnik. Preverite matične podatke (ID za DDV, naslove strank, bančne podatke), vklopite funkcijo in pošljite testni račun. Projekta ne potrebujete in tudi razvijalske hiše ne.

Podobno velja za razširjen ERP, ki je še blizu standardu: izhod dobavi ponudnik ali vaš partner, delo pa sta konfiguracija in testiranje.

Preostanek članka je za podjetja, katerih računi prihajajo iz kode, ki je njihova, ali iz kode, ki je nihče več ne vzdržuje:

• sistemi za obračun na naročniških platformah, tržnicah in v komunalnih podjetjih, ki račune izdajajo programsko in v velikih količinah;
• panožna programska oprema za veleprodajo, gradbeništvo, logistiko ali terenski servis, kjer je ponudnik majhen, počasen ali ga ni več;
• ERP, pri katerih je bil izpis računov pred leti na novo napisan kot lastni tiskalni programi, predloge poročil ali mesečno spajanje dokumentov.

Formati: EN 16931, XRechnung in ZUGFeRD

EN 16931 je evropski standard. Določa semantični model računa (polja, njihov pomen, katera so obvezna in poslovna pravila med njimi) in ga veže na dve sintaksi XML, UBL 2.1 in UN/CEFACT CII.

XRechnung je nemška specifikacija nad EN 16931, ki jo vzdržuje KoSIT: čisti XML v kateri koli od obeh sintaks, ki ga zahtevajo javni organi in je enako veljaven med podjetji. Po podatkih strani KoSIT o XRechnung velja različica 3.0 od 1. februarja 2024 in ostane v veljavi vsaj do 31. julija 2027. Predhodna različica 4.0 je bila objavljena septembra 2026, končna izdaja pa se pričakuje spomladi 2027. Začeli boste na 3.0 in v prvem letu nadgradili.

ZUGFeRD je hibrid: datoteka PDF/A-3 z vgrajenim XML CII. Ljudje berejo PDF, stroji XML. V Franciji se isti format imenuje Factur-X in tehnično sta enaka. FeRD je 4. avgusta 2026 objavil različico 2.5.2. ZUGFeRD obstaja v profilih (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), pogosta vprašanja ministrstva pa sprejemajo ZUGFeRD od različice 2.0.1 dalje, „mit Ausnahme der Profile MINIMUM und BASIC-WL“, torej razen profilov MINIMUM in BASIC-WL.

Pri hibridnem računu šteje XML. Pogosta vprašanja strukturirani del imenujejo „führender Teil“, vodilni del. Če se PDF in XML razlikujeta, je napačen PDF.

Za večino nemških izdajateljev B2B je smiselna privzeta izbira ZUGFeRD v profilu EN 16931, da lahko stranke, ki račune še berejo z očmi, nadaljujejo kot doslej, in XRechnung za javne organe in vse, ki ga zahtevajo. Oba naj nastaneta iz enega notranjega objekta računa, ne iz dveh ločenih poti v kodi.

Kaj se mora spremeniti v vašem sistemu

Račun postane podatek, ne postavitev

Mnogi starejši sistemi račun sestavijo ob tiskanju: besedilo, zlepljeno v predlogo, seštevki, izračunani znotraj poročila, opomba o DDV kot trdo zapisan odstavek. Nič od tega ne preživi EN 16931. Potrebujete shranjen objekt računa, ki vsebuje vsa polja, iz njega pa se izrišeta tako XML kot PDF.

Polja, ki običajno manjkajo ali so napačna:

• Podatki o strankah. Strukturirani naslovi s kodami držav ISO ter ID za DDV ali davčna številka. Bloke naslovov v prostem besedilu je treba razdeliti.
• Datum dobave ali obdobje storitve, shranjen kot podatek in ne kot stavek v glavi.
• Enote. Vsaka količina potrebuje kodo iz Priporočila UN/ECE št. 20 (H87 za kos, KGM za kilogram, DAY za dan). „Stk.“ in „pauschal“ je treba preslikati.
• DDV. Vsaka vrstica nosi kategorijo in stopnjo DDV. Račun ima eno razčlenitev DDV za vsako kombinacijo kategorije in stopnje, seštevki pa se morajo natančno ujemati na dve decimalki. Sistemi, ki DDV zaokrožujejo po vrsticah, tu padejo.
• Besedilo o oprostitvi in obrnjeni davčni obveznosti. Stavek na dnu PDF postane koda kategorije DDV in razlog oprostitve.
• Plačilo. Način plačila, IBAN in pogoji v strukturirani obliki.
• Sklici. Številka naročila ali sklic kupca, po katerem oddelek obveznosti do dobaviteljev vaše stranke usklajuje račune. Če ga nikoli niste shranjevali, ga začnite zajemati zdaj.

Pogosta ovira so vrstice samo z besedilom („dobava po dogovoru“). V strukturiranem računu je vrstica zaračunljiva postavka, zato tako besedilo sodi v opombo.

Popravki, dobropisi in samofakturiranje

Pogosta vprašanja so jasna: kjer velja obveznost e-računa, mora biti tudi popravek e-račun, z vrsto računa za popravek. V EN 16931 se s številko in datumom izdaje sklicuje na predhodni račun, zato mora vaš sistem to povezavo hraniti kot podatek.

Pazite na izrazje. V nemški zakonodaji o DDV je „Gutschrift“ samofakturiran račun, ki ga po predhodnem dogovoru izda kupec (§ 14 Abs. 2 UStG). Tisto, čemur v angleščini rečejo credit note (znižanje cene ali storno), je popravek. Mnogi sistemi za oboje uporabljajo eno vrsto dokumenta. Ločite ju, preden ju preslikate, in če za dobavitelje izdajate samofakturirane račune, te dokumente obravnavajte kot račune, ki jih izdaja vaš sistem.

Končni račun lahko prejšnja delna plačila navede v prilogi, če se strukturirani del nanjo sklicuje; pogosta vprašanja potrjujejo, da to velja tudi po letu 2027.

Preverjanje, preden karkoli odide

KoSIT objavlja odprtokodni validator, ki XML preverja glede na sheme in pravila Schematron, z javno konfiguracijo za XRechnung. Teče iz ukazne vrstice, kot strežniški proces HTTP ali kot knjižnica. Vstavite ga v pot pošiljanja: vsak račun se preveri, preden odide, napaka pa pristane v vrsti, za katero je odgovorna imenovana oseba, z navedbo, katero polje je kršilo katero pravilo.

Pri ZUGFeRD preverite vgrajeni XML glede na pravila svojega profila, posebej preverite vsebnik PDF/A-3 in potrdite, da PDF prikazuje enake seštevke kot XML.

Pošiljanje

Zakon po navedbah pogostih vprašanj „sieht keinen bestimmten Weg vor“: kanala ne predpisuje. E-pošta s priloženo datoteko je v redu. Prav tako API, portal za prenos, skupni pomnilnik znotraj skupine ali (primer ministrstva samega) ključek USB. Peppol za domači B2B v Nemčiji ni obvezen.

Inženirsko delo je vezano na posamezno stranko: naslov za račune, želeni format in evidenca, kaj je bilo poslano kam. Ponovni poskus po neuspelem pošiljanju nosi isti dokument z isto številko računa. Dve številki za eno dobavo sta davčna težava, ne programska.

Arhiviranje

Vsaj strukturirani del je treba hraniti „unversehrt in seiner ursprünglichen Form“, nedotaknjen v izvirni obliki, § 14b UStG pa določa rok hrambe osem let od konca leta izdaje. Shranite natanko tiste bajte, ki ste jih poslali, skupaj z zgoščeno vrednostjo. Ne načrtujte, da boste račune pozneje znova ustvarili iz baze podatkov: do takrat so se podatki in koda že spremenili. Enako velja za e-račune, ki jih prejmete.

Načrt za obdobje od oktobra do decembra 2026

Trinajst tednov je dovolj za osredotočeno gradnjo, če so izvorni podatki v razumnem stanju. Ni pa dovolj za zamenjavo sistema za obračun.

1. in 2. teden: popis in odločitve. Naštejte vsa mesta, kjer nastane račun, vključno z ročnimi dobropisi, končnimi računi projektov in preglednico za eno veliko stranko. Promet za leto 2026 primerjajte s pragom. Izberite privzeti format in se odločite, ali boste generator zgradili sami ali podatke o računih pošiljali prek API ponudnika e-računov.

Od 2. do 4. tedna: analiza vrzeli v podatkih. Tri mesece resničnih računov polje za poljem preslikajte na EN 16931. Označite, kaj manjka, kaj mora postati koda in kaj se izračunava drugače. Tu se pokaže resnična velikost projekta.

Od 4. do 9. tedna: gradnja. Objekt računa, preslikave, izris XML in PDF/A-3, validator v poti pošiljanja, vrsta napak in arhiv. Vzporedno nekdo čisti matične podatke in od strank zbira naslove za račune.

Od 9. do 11. tedna: ponovna obdelava in pilot. Zadnje tri mesece računov spustite skozi novi generator in preverite vsakega. Nato izvedite pilot z nekaj pripravljenimi strankami in jih vprašajte, ali njihovi sistemi datoteke preberejo.

Od 11. do 13. tedna: zamrznitev in priročnik. Decembra zamrznite spremembe. Zapišite, kdo je odgovoren za vrsto napak, kako se izda popravek in kaj se zgodi, ko stranka račun zavrne. Januarski računi za decembrsko delo so že zajeti.

Januar 2027. Začnite in vrsto spremljajte vsak dan do prvega zaključka meseca in prvega obračuna DDV.

Skozi leto 2027. Nadgradnjo na XRechnung 4.0 načrtujte, preden 3.0 preneha veljati, in vse družbe v skupini pod pragom preselite pred 1. januarjem 2028.

Če začnete pozno, okrnite avtomatizacijo, ne veljavnosti izhoda: najprej avtomatizirajte vrste računov z največjim obsegom, redke dokumente pa nekaj tednov ročno pošiljajte prek orodja za e-račune.

Kje dobiti pomoč

Gradimo povezavo med sistemom, ki ustvarja vaše račune, in formatom, ki ga zahteva zakon: spremembe podatkovnega modela, preslikave, preverjanje, pošiljanje in arhiv, v vaši kodi in skupaj z vašo ekipo. Naša storitev integracije e-računov opisuje, kako ti projekti potekajo; če vas obveznost doleti sredi menjave ERP, si oglejte posodobitev ERP. Širši koledar je v našem vodniku po digitalni skladnosti EU 2026.

Smo inženirji, ne davčni svetovalci: vprašanja o obsegu sodijo k vašemu davčnemu svetovalcu (Steuerberater), mi pa gradimo po njegovem odgovoru. Povejte nam, kaj danes ustvarja vaše račune in koliko jih približno odide vsak mesec: pišite na office@c9group.dev.