PDF leta 2028 ne bo e-račun: podjetja morajo pripraviti XML in kontrole

Po pojasnilu Ministrstva za finance bo od 1. januarja 2028 za domače dobave med poslovnimi subjekti obvezna izmenjava strukturiranih e-računov v obliki XML; sam PDF ne zadostuje. Obveznost ne zajema računov potrošnikom in tujim podjetjem. Pri domači izmenjavi med poslovnimi subjekti tudi priponka v e-pošti ne bo ustrezna pot.

Podjetje mora zato povezati izdajo oziroma prejem XML z varno e-potjo, povratnimi sporočili, notranjo odobritvijo in hrambo. Priprava se začne s popisom poti računa: kdo ustvari podatke, kdo vidi zavrnitev, kdo popravi napako in kje ostane izvirnik. Program, ki zna datoteko samo izvoziti, še ne pokaže, ali je račun prispel in bil obdelan.

Razmejite račune in popišite oba toka

Najprej ločite račune za domače poslovne subjekte od računov za potrošnike in tuje partnerje. Pri vsaki skupini zapišite, katere listine nastajajo, v katerem programu in po kateri poti jih danes pošiljate ali prejemate. Poleg običajnega računa upoštevajte tudi dobropise, bremepise in avansne račune, če jih uporabljate.

Pri izdanem računu sledite podatkom od naročila do odpreme: kdo preveri podatke kupca, kdo odobri vsebino, kateri sistem pripravi XML in kje se prikaže status dostave. Pri prejetem računu določite, kdo ga prevzame, poveže z naročilom ali dobavo, vsebinsko potrdi in preda v knjiženje. Če pri tem sodeluje računovodski servis, v popisu označite tudi trenutek predaje ter osebo, ki po predaji še spremlja status.

Tak popis razkrije mesta, kjer se lahko račun ustavi brez opozorila. Posebej preverite, ali se ob prenosu med sistemi ohranijo izvirna datoteka, podatki o pošiljanju in razlog morebitne zavrnitve. To so konkretne zahteve, s katerimi lahko preverite ponudbo programske opreme, namesto da se oprete zgolj na splošno navedbo o podpori e-računom.

Preverite XML, e-pot in povratna sporočila

Pri ponudniku programa zahtevajte opis podprtega standarda, uvoza in izvoza ter povezave z izbrano e-potjo. V vzorčnem računu preverite identifikacijo partnerja, podatke o postavkah, sklice in priloge, ki jih vaš postopek dejansko potrebuje. Človeku berljiv prikaz pomaga pri pregledu, za nadaljnjo obdelavo pa mora potovati strukturiran zapis.

Uspešno ustvarjen XML je šele začetek izmenjave. Določite, kje boste videli sporočilo o dostavi ter kje vsebinsko potrditev ali zavrnitev prejemnika. Če obvestilo obstane pri ponudniku e-poti ali v ločeni aplikaciji, mora biti jasno, kako pride do zaposlenega, ki lahko popravi podatek, in kako ta preveri izid ponovnega pošiljanja.

Pri izbiri poti preverite tudi dogovorjeni način dela ob prekinitvi storitve: kdo prejme obvestilo o zastoju, kje čakajo neposlani računi in kako se po obnovi povezave preveri njihov status. Enako pomembna je možnost pridobitve podatkov o dostavi, če podjetje pozneje menja ponudnika ali rešuje spor s poslovnim partnerjem.

Določite odgovornost za zavrnitve in hrambo

Razdelitev dela med podjetjem, računovodskim servisom in ponudnikom e-poti naj bo zapisana za vsak korak, ne samo za pošiljanje. V dogovoru določite izvajalca, osebo za odločitev ob napaki in podatek, s katerim je mogoče preveriti, da je bilo opravilo končano. Samodejni uvoz prejetega računa še ne pomeni vsebinske odobritve ali pravilnega knjiženja.

• Podjetje skrbi za podatke o partnerjih, vsebinsko potrjevanje in uporabniške pravice. Imenuje osebo, ki prejme zavrnitve, odloči o popravku in preveri nov status.
• Računovodski servis po dogovoru prevzema listine, preverja podatke za knjiženje ter sporoča ugotovljene napake. Pogodba naj pove, ali spremlja tudi povratna sporočila in opravlja naloge hrambe.
• Ponudnik e-poti izvaja dogovorjeno izmenjavo in omogoča dostop do povratnih sporočil. Podjetje naj preveri, katere podatke o prenosu lahko pridobi in kakšen je postopek ob tehnični motnji.

Za vsako zavrnitev določite, kdo razločuje tehnično napako od vsebinske, kdo odobri spremembo in kako se popravljeni račun poveže s prvotnim poskusom. Pri hrambi določite mesto izvirnih datotek, pravice dostopa in način poznejšega priklica. Po 18. členu ZIERDED za hrambo skrbita izdajatelj in prejemnik, ponudnik e-poti pa dostavljeni dokument izbriše, razen če se z naročnikom dogovori za daljšo hrambo.

Preizkusite dostavo, zavrnitev in izpad

Minimalni preizkus vključuje izdan in prejet račun ter sodelovanje pomembnega kupca in dobavitelja. Pred začetkom se dogovorite, kdo pri partnerju potrdi prejem in kateri status šteje kot uspešen rezultat. Preverjanje strukture XML je koristno, vendar samo ne pokaže, ali je račun pri partnerju prispel, bil potrjen in pravilno povezan z njegovim postopkom.

1. Pošljite veljaven račun. Preverite podatke po uvozu pri prejemniku, povratno sporočilo in shranjeni izvirnik.
2. Prejmite veljaven račun. Preverite povezavo z naročilom, vsebinsko odobritev, knjiženje in poznejši priklic datoteke.
3. Pošljite preskusni račun z namerno napačnim obveznim podatkom. Zabeležite razlog zavrnitve in osebo, ki prejme obvestilo.
4. S partnerjem preizkusite vsebinsko zavrnitev, popravek in ponovno pošiljanje. Preverite sled med obema poskusoma.
5. Preizkusite ponovljeno pošiljanje istega računa ter nedosegljivo e-pot. Po obnovi preverite, ali je račun dostavljen in ali ni bil obdelan dvakrat.

Pri vsakem scenariju zapišite pričakovani in dejanski rezultat ter lastnika odprave napake. Preskus je zaključen, ko lahko odgovorna oseba preveri končni status in prikliče račun iz hrambe, ne zgolj ko program sporoči, da je datoteko ustvaril.

Časovnica priprave od 2026 do 2028

Pregled Podjetniškega portala leto 2026 namenja popisu procesov in izbiri rešitve, leto 2027 povezovanju in preizkusom; določbe za ponudnike e-poti se začnejo uporabljati 1. aprila 2027, seznam ponudnikov pa se vzpostavi 1. oktobra 2027. Popis in razdelitev odgovornosti sta predlagana izvedbena koraka, ne samostojna zakonska roka. Po vzpostavitvi seznama bo mogoče izbiro ponudnika povezati tudi z objavljenimi pogoji njegove storitve.

Pred začetkom obvezne izmenjave naj podjetje s ključnimi partnerji dokonča preizkuse v obe smeri in odpravi napake, ki jih pokažejo zavrnitve ali motnje. Končni dogovor naj določa, kdo na dan rednega poslovanja spremlja povratna sporočila, kdo prevzame nerešen račun ob odsotnosti skrbnika in kako se po prekinitvi poti preveri, da noben račun ni ostal neposlan.

Preberite tudi:

• Strukturiran izhod še ni pravilna vsebina: JSON potrebuje dodatno kontrolo