eRačuni 🔔

Obveza se uvodi fazno, a ključno je razlikovati obvezu primanja od obveze slanja eRačuna.

Obveza PRIMANJA eRačuna

• Od 1. siječnja 2026.: Obvezu zaprimanja eRačuna i provedbu fiskalizacije zaprimljenih eRačuna imaju svi primatelji eRačuna definirani Zakonom. To uključuje sve porezne obveznike (i one u sustavu PDV-a i one izvan njega) te tijela javne vlasti.

Obveza SLANJA eRačuna

Obveza slanja eRačuna uvodi se u dvije faze:

• Od 1. siječnja 2026.: Obvezu slanja eRačuna imaju porezni obveznici sa sjedištem, prebivalištem ili uobičajenim boravištem u tuzemstvu koji su upisani u registar obveznika PDV-a.

• Od 1. siječnja 2027.: Obveza slanja eRačuna proširuje se i na preostale skupine poreznih obveznika koji nisu upisani u registar obveznika PDV-a.

Primjena sustava ovisi o tome tko je kupac (B2C ili B2B) te, u B2B segmentu, o načinu plaćanja.

A. Fiskalizacija u krajnjoj potrošnji (F1.0) - B2C

Ovo je sustav namijenjen poslovanju s građanima (potrošačima).

• Obveza: Primjenjuje se kada obveznik fiskalizacije (obveznik poreza na dohodak od samostalne djelatnosti ili poreza na dobit) izdaje račun građaninu u prometu u krajnjoj potrošnji.

• Način plaćanja: Od 1. siječnja 2026. obveza F1.0 vrijedi za sve načine plaćanja, uključujući gotovinu, kartice, transakcijski račun i ostalo.

B. Izdavanje i fiskalizacija eRačuna (F2.0) - B2B i B2G

Ovo je sustav namijenjen poslovanju između poreznih obveznika (B2B) i s tijelima javne vlasti (B2G).

• Obveza: Primjenjuje se za tuzemne transakcije kada je primatelj računa drugi porezni obveznik (bez obzira je li u sustavu PDV-a ili ne) ili tijelo javne vlasti.

• Napomena o uvođenju: Obveza slanja eRačuna za obveznike upisane u registar PDV-a kreće 1. siječnja 2026.. Za obveznike koji nisu upisani u registar PDV-a (obveznici poreza na dohodak/dobit) te za tijela javne vlasti izvan sustava PDV-a, obveza slanja kreće 1. siječnja 2027..

• Način plaćanja: Ovo je obvezan sustav za B2B transakcije koje se plaćaju transakcijski (virmanski).

C. Iznimka: Primjena F1.0 u B2B poslovanju

Zakon definira iznimku kada se B2B transakcija ne mora provesti kroz F2.0 (eRačun), već se umjesto toga primjenjuje F1.0.

• Uvjet: Transakcija se mora plaćati gotovinom ili karticom.

• Postupak: U tom slučaju, izdavatelj je dužan provesti postupak fiskalizacije u krajnjoj potrošnji (F1.0). Pritom mora u sustav za fiskalizaciju dostaviti i OIB primatelja računa.

• Važno: Ako se primijeni ovaj postupak (F1.0), za tu transakciju ne može se izdati i fiskalizirati eRačun (F2.0).

👉 Primjena u Luceedu

• Za račune iz modula Veleprodaja, bit će omogućeno da se prema tipu komitenta (partnera) automatski određuje je li kupcu potrebno poslati eRačun, odnosno primjenjuje li se F1.0 ili F2.0 postupak fiskalizacije.

• Za račune iz modula Maloprodaja, bit će omogućeno da izdavatelj, u slučaju plaćanja gotovinom ili karticom, odabere postupak koji će se provesti (slanje i fiskalizacija eRačuna (F2.0) ili fiskalizacija računa u krajnjoj potrošnji (F1.0)), dok je u slučaju transakcijskog plaćanja obvezno slanje eRačuna.

Koristimo Luceed ERP i izdajemo račune za krajnju potrošnju (B2C) koje fiskaliziramo prema F1.0 pravilima, ali i eRačune poslovnim partnerima (B2B) koje ćemo trebati fiskalizirati prema F2.0 pravilima. Moramo li zbog toga definirati dva odvojena naplatna uređaja i imati dvije odvojene slijednosti brojeva?

Ne, odvojena slijednost nije obavezna. Možete koristiti jedinstvenu slijednost brojeva za obje vrste računa, za jedan naplatni uređaj.

To je potvrdila i Porezna uprava (u službenom odgovoru na Pitanje br. 27), koja je navela da iako se radi o dva različita procesa:

Ukoliko se na tržištu razvije rješenje koje će u jednom postupku imati ta dva različita programska rješenja, teoretski slijednost računa bi mogla biti ista, uz uvjet da je navedeno propisano internim aktom.

Luceed ERP je upravo takvo rješenje. Sustav prepoznaje o kojoj se vrsti računa radi (B2C ili B2B) te automatski primjenjuje ispravan postupak (slanje JIR-a za F1.0 ili slanje eRačuna za F2.0), sve unutar jednog naplatnog uređaja i jedinstvene slijednosti brojeva.

Važno je samo da u svom internom aktu propišete da koristite jedinstvenu slijednost na tom naplatnom uređaju, oslanjajući se na mogućnosti svog ERP sustava.

Službeni odgovor PU (br. 27.):

U poslovanju se često događa da se oporezivi događaj (isporuka dobara, obavljanje usluge ili primitak uplate predujma) dogodi u jednom obračunskom razdoblju, dok se račun za tu transakciju izdaje u sljedećem razdoblju.

Prema Zakonu o PDV-u, ključan podatak za ispravan obračun PDV-a je datum isporuke dobara ili obavljenih usluga (ili datum primitka predujma). PDV prijava popunjava se isključivo prema datumu nastanka oporezivog događaja.

Budući da računi s transakcijskim plaćanjem (B2B segment) do sada nisu podlijegali fiskalizaciji, u nekim se slučajevima prakticiralo se ručno mijenjanje datuma nastanka porezne obveze (u Luceedu polje Datum) na datum iz prethodnog mjeseca, iako je sam račun kreiran u tekućem mjesecu. Iako sistemski datum i vrijeme kreiranja dokumenta (polje Kreiran) nisu bili promjenjivi, ovaj ključni datum za PDV jest.

S uvođenjem Fiskalizacije 2.0, svaki izdani eRačun bit će fiskaliziran, čime Datum postaje nepromjenjiv. To znači da nakon što je račun jednom izdan i poslan (pri tome fiskaliziran), više neće biti moguće mijenjati datum nastanka porezne obveze. Time dosadašnja praksa naknadne izmjene tog datuma više nije moguća.

Pitanje: Kako, unutar novih pravila, izdati ispravan i zakonski usklađen eRačun u tekućem mjesecu, a da se obveza PDV-a nedvojbeno odnosi na prethodno razdoblje?

👉 Primjena u Luceedu

Ispravan i zakonski usklađen eRačun u ovakvoj situaciji izdaje se primjenom standardiziranog principa razdvajanja datuma izdavanja od datuma nastanka porezne obveze. Sustav eRačuna i Fiskalizacije 2.0 zapravo samo formalizira princip koji Luceed već primjenjuje.

Ključno je razumjeti i ispravno koristiti dva datuma na računu:

• Datum i vrijeme IZDAVANJA: Ovo je stvarni, sistemski zabilježen i nepromjenjiv trenutak kada je račun kreiran u Luceedu (podatak iz polja Kreiran). S uvođenjem Fiskalizacije 2.0, ovaj podatak postaje službeni datum i vrijeme izdavanja računa koji se šalje Poreznoj upravi.

• Datum nastanka OBVEZE PDV-a: Ovo je datum isporuke, obavljene usluge ili primitka predujma. To je datum iz polja Datum na računu i on određuje u koje obračunsko razdoblje ulazi obveza PDV-a.

Nakon slanja eRačuna, datum nastanka obveze PDV-a (polje Datum) neće biti moguće mijenjati. Zato je važno odabrati ispravan proces u Luceedu prije izdavanja računa.

Mogućnost unosa datuma nastanka porezne obveze ovisi o poslovnom procesu. Primjerice, prilikom generiranja računa iz jedne ili više otpremnica, Luceed vam omogućuje odabir datuma u polju Datum. S druge strane, kod snimanja isporuke direktno računom (npr. iz naloga prodaje) to nije moguće jer se podrazumijeva da je isporuka nastala na dan kreiranja računa.

Neovisno o poslovnom procesu, kada je zaprimljena avansna uplata u jednom obračunskom razdoblju, a isporuka i konačni račun slijede u idućem, ispravno i zakonski obvezujuće rješenje je izdavanje računa za predujam. Račun za predujam se izdaje s datumom primitka uplate, čime se obveza PDV-a ispravno evidentira u pripadajućem mjesecu.

Kako bi se izbjeglo ručno kreiranje računa za predujam, Luceed nudi i automatizirano rješenje kroz opciju Povezivanje uplata s dokumentima. Ovaj proces, ovisno o postavkama, može automatski kreirati račun za predujam na datum uplate, a prilikom izrade konačnog računa automatski će izvršiti i njegovo storniranje. Time se osigurava potpuna usklađenost uz minimalan napor.

Razumijemo važnost ovog procesa, posebno u kontekstu nadolazeće primjene eRačuna.

Do sada je u sustavu vrijedilo pravilo da se storniranjem računa stornira i otpremnica samo ako je isporuka robe zabilježena direktno na računu (čime je otpremnica kreirana automatski). Ako ste u procesu prvo kreirali otpremnicu, a zatim iz nje račun, storniranje računa nije utjecalo na otpremnicu.

Svjesni smo da će u novom procesu eRačuna (F2.0) često dolaziti do potrebe za ispravkom računa (zbog odbijanja od strane kupca), dok je sama isporuka (otpremnica) bila ispravna i ne treba je dirati.

S obzirom na to, pripremamo prilagodbu procesa koja će biti aktivna s početkom primjene F2.0.

Bit će omogućeno da u slučaju potrebe za storniranjem poslanog eRačuna (npr. zbog odbijanja), stornirate isključivo račun (RA). Pripadajuća otpremnica (OT) neće biti stornirana i ostat će važeća.

Time osiguravamo da iz originalne otpremnice (koja ima ispravan datum isporuke i razduženja skladišta/WMS-a) možete odmah kreirati novi, ispravan račun i ponovno ga poslati.

U nadolazećoj verziji Luceeda bit će moguće odabrati poslovni proces P99 – “Poslovni proces koji definira kupac” na kartici Dodatni podaci, u polju Poslovni proces na svim veleprodajnim dokumentima i računima.

1. Kada se u polju Poslovni proces odabere P99, sustav će automatski prikazati novo polje za slobodan unos: Oznaka kupca.

2. U to ćete polje unositi točnu oznaku koju je kupac dostavio.

3. Polje za unos oznake kupca će biti obavezno ako je odabran P99.

4. Ako se odabere bilo koji drugi proces (P1–P12), dodatno polje neće biti prikazano - ponašanje ostaje kao i dosad.

P99 se uvodi jer dio kupaca zahtijeva slanje vlastite oznake procesa u eRačunu, što je predviđeno novim specifikacijama koje stupaju na snagu 1.1.2026.

Da. Preuzimanje eRačuna odvija se putem naše platforme Interconnect, koja komunicira s odabranim informacijskim posrednikom. Ovisno o tome koristite li naše DMS rješenje, proces se razlikuje u jednom koraku:

1. Korisnici bez Luceed DMS-a: Sustav će vam omogućuti da iz samog Luceeda pokrenete preuzimanje eRačuna s Interconnecta direktno u knjigu URA.

2. Korisnici s Luceed DMS-om: eRačuni s Interconnecta prvo dolaze u DMS na pregled i odobravanje (knjiženje, raspodjelu po mjestima troška, …). Nakon što su digitalno odobreni, sustav će ih automatizmom knjiži u URA-u unutar Luceeda, bez potrebe za ručnim preuzimanjem.

Iako Luceed API nudi metode za dohvat podataka o računu (u standardnom JSON formatu) ili samog dokumenta u PDF-u, direktan dohvat računa u UBL formatu putem Luceed API-ja nije podržan.

Međutim, to ne znači da ne možete doći do željenih podataka. Za razmjenu i dohvat standardiziranih elektroničkih dokumenata (u UBL formatu) koristimo naše specijalizirano rješenje – Interconnect.

Što trebate učiniti?

• Za postojeće Luceed korisnike: Ako želite preuzimati UBL datoteke (npr. za potrebe DMS sustava), potrebno je aktivirati odgovarajuću Interconnect uslugu. Slobodno nas kontaktirajte kako bismo vas uputili u proces aktivacije.

• Za integratore (developere trećih strana): Ako razvijate rješenje koje treba dohvaćati UBL račune iz Luceeda, integraciju je potrebno napraviti s Interconnect API-jem, a ne direktno s Luceed API-jem. Sva potrebna tehnička dokumentacija za integraciju dostupna je na našem Documentation HUB-u.

Potrebno je razlikovati zakonski eRačun od komercijalne EDI razmjene.

Podaci kao što su Identifikator klasifikacije artikla - KPD (BT-158) , Oznaka operatera (HR-BT-4) i Tip poslovnog procesa (BT-23) su obvezni elementi propisani tehničkom specifikacijom uporabe eRačuna. Naš sustav će osigurati da su ti podaci uredno sadržani u eRačunu koji se šalje vašem kupcu kao službeni, zakonski valjan dokument, te iz kojeg se provodi fiskalizacija premu sustavu Porezne uprave.

Što se tiče samog EDI kanala (postojeći formati za razmjenu narudžbi, otpremnica i sl.), navedeni podaci nisu dio standardne strukture niti su nužni za komercijalnu i logističku obradu dokumenata u tom formatu. Budući da su ti podaci vezani isključivo uz porezni nadzor, oni će biti sadržani u XML-u eRačuna, dok se standardni EDI format u ovom trenutku neće proširivati tim specifičnim fiskalizacijskim elementima.

Ukratko: Zakonska usklađenost bit će osigurana kroz XML eRačun, dok EDI razmjena nastavlja funkcionirati prema dosadašnjim logističkim standardima.

Važno je naglasiti da eRačun ne sadrži sustavnu oznaku kojom bi se automatski moglo prepoznati radi li se o računu za osnovno sredstvo, robu, trošak ili neku drugu namjenu. Takva informacija nije standardizirani dio eRačuna i nije dostupna za automatsku obradu.

Zbog toga Luceed razvrstava ulazne eRačune isključivo prema tipu eRačuna i postavkama u šifrarniku Tipovi knjiga – URA. Sustav koristi sljedeći redoslijed:

1. Ako postoji korisnički definirana knjiga s postavljenim Tipom eRačuna, taj tip eRačuna smjestit će se u tu knjigu.

2. Ako takva knjiga ne postoji, primjenjuje se osnovno pravilo sustava:

   • 380 – Račun, 381 – Odobrenje, 383 – Terećenje → Dobra i usluge u tuzemstvu

   • 386 – Račun predujma → Dani predujmovi

Korisnici mogu prema potrebi dodati vlastite tipove knjiga i povezati ih s određenim tipovima eRačuna, čime se automatizira razvrstavanje prema poslovnim potrebama.

Više informacija dostupno je u korisničkoj dokumentaciji:

• Razvrstavanje eRačuna u knjige URA

• Tipovi knjiga – URA

Luceed DMS (opcionalno)

Za korisnike koji budu koristili Luceed DMS (kada bude dostupan), bit će moguće dodatno definirati u koju knjigu URA se račun smješta, i to prema dodatnim kriterijima, primjerice prema dobavljaču ili putem ručnog odabira knjige prilikom obrade računa u DMS-u. Na taj način korisnici dobivaju potpunu kontrolu nad razvrstavanjem ulaznih računa, što nije moguće postići isključivo automatskim prepoznavanjem iz sadržaja eRačuna.

Luceed DMS je opcionalan za korištenje, a njegovo puštanje u produkciju planirano je početkom iduće godine.

Ne, Luceed trenutno ne podržava automatizirani proces samoizdavanja računa (proces P12 u sustavu eRačuna).

S obzirom na visoku tehničku složenost implementacije ovog specifičnog procesa i relativno malu učestalost korištenja među našim korisnicima, odlučili smo da ovu funkcionalnost nećemo ugrađivati u sustav u ovoj fazi.

Što to znači za vas? Ako ste do sada koristili model samoizdavanja (bilo da ste vi izdavali račune u ime dobavljača ili je kupac izdavao račune u vaše ime), molimo vas da od 1. siječnja 2026. sa svojim poslovnim partnerima dogovorite prelazak na standardni način izdavanja računa.

To u praksi znači:

• Ako ste vi dobavljač (npr. komitent): Vi morate kreirati i fiskalizirati izlazni račun prema kupcu kroz Luceed i poslati ga njemu, umjesto da on kreira račun u vaše ime.

• Ako ste vi kupac (npr. komisionar): Umjesto da vi kreirate račun u ime dobavljača, zatražite od dobavljača da vam ispostavi standardni eRačun za isporučenu robu ili uslugu.

Da, OIB i GLN se šalju istovremeno, ali se unose u zasebna polja unutar XML strukture eRačuna. Ova dva identifikatora se međusobno ne isključuju jer služe različitim svrhama:

• OIB (porezna identifikacija): Obvezan je podatak za proces fiskalizacije i služi za nedvojbenu pravnu identifikaciju primatelja računa u sustavu Porezne uprave.

• GLN (logistička identifikacija): Služi za precizno definiranje mjesta isporuke, poslovnice ili specifičnog odjela unutar sustava kupca, što olakšava automatsku obradu računa.

Pravila unosa i hijerarhija u sustavu (Luceed)

Kako bi se osigurala točnost podataka, sustav primjenjuje automatiziranu hijerarhiju pri povlačenju GLN koda:

1. Razina korisnika: Ako je na računu odabran partner u polju Korisnik (lokacija ili poslovnica isporuke), sustav primarno povlači GLN iz matičnih podataka tog partnera.

2. Razina partnera: Ako na partneru unijetom u polje Korisnik GLN nije definiran, sustav će povući glavni GLN iz partnera postavljenog u polju Partner.

Gdje unijeti podatke?

• Matični podaci > Partneri: Polje GLN u osnovnim podacima partnera.

Ako zbog specifičnosti poslovanja koristite više softverskih rješenja i aplikacija za različite dijelove poslovanja (npr. jedno rješenje za maloprodaju, a drugo za veleprodaju), moguće je koristiti i više informacijskih posrednika. Pritom je ključno razlikovati dva procesa:

1. odabir posrednika za zaprimanje eRačuna

2. davanje ovlaštenja posrednicima za slanje podataka

1. Zaprimanje eRačuna – odabir jednog posrednika

Za zaprimanje eRačuna od svojih dobavljača možete imati potvrđenu samo jednu adresu (pristupnu točku) u sustavu Porezne uprave. To znači da u FiskAplikaciji (ePorezna) birate isključivo jednog posrednika preko kojeg ćete zaprimati sve ulazne eRačune.

2. Slanje eRačuna i eIzvještavanja – davanje ovlaštenja

Za fiskalizaciju eRačuna možete dati neograničen broj ovlaštenja, ovisno o tome koliko različitih aplikacija i posrednika koristite. Za svakog posrednika koji u vaše ime šalje podatke prema Poreznoj upravi potrebno je:

• dodati zasebno ovlaštenje u FiskAplikaciji

• navesti OIB tog posrednika

• definirati datum početka važenja ovlaštenja

Ako koristite više aplikacija koje rade preko različitih posrednika, ovlaštenje morate dati za svakog od njih pojedinačno.

Važna napomena: Ako za nekog posrednika nije definirano odgovarajuće ovlaštenje, svi računi ili izvještaji poslani iz tog sustava neće biti ispravno zaprimljeni u Poreznoj upravi i smatrat će se tehnički nevažećima u procesu fiskalizacije.