Arhitektura s dva kanala za eRačun: AS4 razmjena i fiskalizacija
Ako vodite ERP, web shop ili vlastiti sustav koji mora izdavati hrvatske eRačune, prvo što morate razumjeti jest da gradite dvije integracije, a ne jednu.
Prva je razmjena. Vaš račun odlazi kao UBL 2.1 XML preko AS4 veze do pristupne točke kupca. Druga je fiskalizacija i prijava Poreznoj upravi, koja ide preko drugog sučelja, s vlastitim shemama i vlastitim potpisivanjem poruka. Porezna uprava izričito navodi da izdavatelj fiskalizira izdani eRačun odvojeno od postupka razmjene, u trenutku izdavanja, a kod samoizdavanja najkasnije u roku od pet radnih dana od izdavanja.
Dva kanala, dva skupa načina na koje stvari mogu poći po zlu. Račun može stići kupcu, a da ne bude fiskaliziran, ili obrnuto. Većina onoga što je objavljeno o Fiskalizaciji 2.0 pisana je za vlasnika koji se pita što mora. Ovaj tekst pisan je za onoga tko to mora i spojiti.
Kako stvarno stoje rokovi
Zakon o fiskalizaciji (NN 89/2025) stupio je na snagu 1. rujna 2025., a primjenjuje se od 1. siječnja 2026.
Od 1. siječnja 2026. porezni obveznici upisani u registar obveznika PDV-a izdaju i fiskaliziraju eRačune u domaćem B2B prometu. Svi ostali moraju moći zaprimiti eRačun i fiskalizirati primitak. Od 1. siječnja 2027. i porezni obveznici izvan sustava PDV-a moraju izdavati i fiskalizirati.
Ako ste u sustavu PDV-a, a većina tvrtki koje vode ERP ili web shop iole ozbiljnijeg obujma jest, obje obveze na snazi su od siječnja 2026. Rok koji je još pred nama odnosi se na izdavatelje izvan sustava PDV-a. U svakom slučaju, izdavanje je ona strana koja zadire u vaš softver.
To je dio koji inženjeri podcjenjuju. Pravilnik o eRačunu (NN 11/2026), donesen na temelju članka 64. Zakona i na snazi od 31. siječnja 2026., definira tehničku specifikaciju kao dokumentaciju objavljenu na portalu Fiskalizacija 2.0 Porezne uprave i čini je obvezujućom.
Srodne usluge
Opišite nam svoj projekt
Odgovaraju vam inženjeri koji bi ga gradili, pisanim putem, čim prije.
Pretplatite se na naš newsletter i jednom mjesečno primajte praktične savjete o webu, softveru i AI-ju.
Izmjena te dokumentacije stoga je promjena vaše zakonske obveze, a ne stavka koju netko može ostaviti u backlogu. Tretirajte verziju specifikacije kao fiksiranu ovisnost. Zabilježite protiv koje ste verzije gradili i provjerite je kad izađe nova.
U trenutku pisanja objavljena tehnička specifikacija je verzija 1.8 od 12. ožujka 2026., sa sintaksom UBL 2.1. Prije nego što krenete, provjerite aktualnu verziju na stranici sa specifikacijama.
Nacionalna pravila nadograđuju se na europsku normu EN 16931, a ne zamjenjuju je: nacionalna specifikacija primjene osnovnog računa plus hrvatska proširenja. Usklađen račun nosi CustomizationID u ovom obliku, kao jedan neprekinuti niz:
Nemojte ga hard-kodirati prema tekstu s bloga. Usporedite ga s verzijom specifikacije prema kojoj gradite.
Na strani razmjene profil pristupne točke je eRačun-AS4, koji slijedi CEF eDelivery AS4 Profile v1.15 i sužava atribute koje CEF profil ostavlja otvorenima. Uz njega idu i usluga imenika, koja utvrđuje tko zaprima račune za pojedinog poreznog obveznika, te usluga metapodataka.
Četiri načina da ispunite obvezu izdavanja
MIKROeRAČUN preko ePorezne
Kada odgovara: Vrlo mali obujam, računi se ionako pišu ručno. Prvo provjerite uvjete i ograničenja. Što vas košta: Ništa se ne gradi. Gdje boli: Ručno prepisivanje. Vaš vlastiti sustav nikad ne sazna da je račun otišao.
SaaS za fakturiranje kao glavna evidencija
Kada odgovara: Vaš sadašnji sustav ionako nije mjesto na kojem računi zapravo nastaju. Što vas košta: Pretplata i migracija. Gdje boli: Dva kataloga proizvoda koja treba držati usklađena, a SaaS drži vaše podatke o računima.
Povezivanje vašeg sustava s informacijskim posrednikom
Kada odgovara: Račune generira softver o kojem već ovisite. Što vas košta: Integracijski projekt, plus ono što posrednik naplaćuje. Gdje boli: Mapiranje polja i obrada grešaka ostaju na vama.
Vlastita pristupna točka
Kada odgovara: Platforma ste koja izdaje račune u ime mnogo tvrtki. Što vas košta: Implementacija AS4 profila i praćenje svake izmjene. Gdje boli: Usklađenost sa specifikacijom postaje dio vašeg proizvoda.
Za većinu tvrtki s ERP-om ili web shopom koji radi, treći redak je pošten odgovor. Zamjena sustava koji funkcionira samo da biste zadovoljili XML format skup je način rješavanja problema mapiranja. Napominjemo da Zakon ne traži da usluga posrednika bude naplatna, nego samo da odnos bude uređen ugovorom, pa usporedite uvjete umjesto da pretpostavljate jedinstvenu tržišnu cijenu.
Što nedostaje vašem modelu podataka
To je ono što dvotjednu integraciju pretvori u dvomjesečnu. Format je dokumentiran. Vaši podaci nisu oblikovani za njega.
Praznine su gotovo uvijek iste:
Identifikacija kupca. Strukturirani račun traži kupca razriješenog do identifikatora, a ne naziv tvrtke koji je prodavač utipkao u slobodno polje. Ako vaša tablica kupaca ima jedan tekstualni blok s adresom i nema stupac za OIB, to je posao na shemi prije nego što uopće postane posao oko XML-a.
Klasifikacija stavki. Svaka stavka treba svoju KPD 2025 oznaku: najmanje šest znamenaka, pisanih s točkama, primjerice 47.82.20. Klasifikacija je usklađena s europskom CPA 2.2, a oznake se pretražuju kroz aplikaciju KLASUS Državnog zavoda za statistiku. Oznake se primjenjuju na eRačune, ne na B2C fiskalne račune. Mapiranje postojećeg kataloga je podatkovni projekt i ne da se paralelizirati, jer svaku odluku mora donijeti netko tko poznaje proizvode.
Zaokruživanje i ukupni iznosi. Vaš sustav vjerojatno zaokružuje negdje gdje norma to ne očekuje. Iznosi stavki koji se ne slažu s ukupnim iznosima računa padaju na poslovnim pravilima EN 16931, poput BR-CO-10 i BR-CO-13, već na pristupnoj točki, prije nego što kupac uopće vidi dokument.
Odobrenja i ispravci. Timovi izgrade put za račun, puste ga u rad, a onda otkriju da put za ispravak traži vlastitu vrstu dokumenta i referencu na izvorni račun.
Dokumenti koji nisu računi. Predujmovi i naknadna odobrenja imaju vlastita pravila. Rano odlučite koji su vaši dokumenti u opsegu.
eRačun je poruka sustavu koji je može odbiti. Tu leži operativni dio posla.
Gradite za odbijanje od prvog commita. Račun koji padne na validaciji otišao je iz vašeg sustava, ali za kupca ne postoji, dok ga vaše knjigovodstvo veselo prikazuje kao izdanog. Zapis o računu treba status koji odražava ono što je mreža rekla, a ne ono što je vaše sučelje pretpostavilo.
Odlučite unaprijed koji vam je ključ idempotentnosti i tu odluku zapišite. UBL ID računa i identifikator fiskalizacijske poruke nisu isti ključ i nemaju istu semantiku. Ponovno slanje mora koristiti isti ključ, a ne generirati novi, inače vam ponovni pokušaj postane duplirani račun.
Čuvajte XML, a ne njegov PDF prikaz, kroz zakonski rok čuvanja, zajedno s potpisom i potvrdom o zaprimanju. XML je račun. PDF ne dokazuje ništa o tome što je mreža primila.
I pobrinite se da netko to primijeti. Red čekanja koji tiho stane kvar je koji stvarno košta, jer nitko ne sazna dok kupac ne pita gdje mu je račun. Dnevno usklađivanje između računa izdanih u vašem sustavu i računa koje je mreža potvrdila pretvara tromjesečni problem u jednodnevni.
Kako to radimo
Ovo tretiramo kao integraciju, ne kao zamjenu. Račun ostaje ondje gdje nastaje. Između vašeg sustava i posrednika stoji sloj za automatizaciju procesa: mapira vaša polja na specifikaciju, validira prije slanja, zapisuje potvrdu natrag na zapis o računu, ponavlja slanje na dogovorenom ključu i podiže iznimku za čovjeka kad se dokument ne može mapirati. Taj sloj vrtimo self-hosted u EU ili na vašim vlastitim poslužiteljima, tako da račun dobije posrednik, a nitko drugi ne drži kopiju vaših knjiga.
Isti obrazac koristimo i za ostale poslove , a eRačun je dobar prvi slučaj, jer ispravan izlaz definira netko drugi pa ga je lako testirati.
Pošaljite nam kratak opis sustava iz kojeg danas izdajete račune i reći ćemo vam koji bismo od četiri puta odabrali i zašto.
