Knjiženje fiskalnih računa u KPR/KUF iz Excela

Fiskalni računi se za KPR/KUF najbrže obrađuju tako što se iz QR koda, slike ili PDF-a izvuku dobavljač, PIB dobavljača, datum, PFR broj, osnovica, PDV, ukupan iznos i status PIB-a kupca u jednu Excel tabelu. Ručni unos ima smisla kada jedan klijent donese mali broj računa, QR čitač je dobar za uredne račune srednjeg obima, a ERP uvoz ili AI ekstrakcija postaju praktičniji kada agencija mesečno obrađuje veće batch-eve, više klijenata i mešovite fajlove.

Za knjigovodstvenu agenciju, knjiženje fiskalnih računa u KPR Excel nije pitanje da li je slika računa sačuvana. Pravo pitanje je da li svaki račun može da postane red koji je dovoljno čist za pregled, dopunu i uvoz u softver koji klijent već koristi. Na kraju meseca to obično nisu uredni pojedinačni dokumenti. Klijenti šalju fotografije iz telefona, skenirane PDF-ove, papirne račune iz koverti, QR linkove, račune za gorivo, parking, terminale, ugostiteljstvo, prevoz i sitne nabavke.

Zato je cilj batch obrade jedna kontrolna tabela, ne samo digitalna arhiva. U toj tabeli knjigovođa vidi kome račun pripada, ko je dobavljač, koji je PFR identifikator, da li postoji PIB kupca, kolika je osnovica, koliki je PDV i gde je original ako treba otvoriti sliku ili PDF. Tek tada račun ima praktičnu vrednost za KPR, KUF, PDV proveru i mesečno zatvaranje.

Metoda zavisi od obima i kvaliteta ulaza. Ako klijent ima manje od 30 fiskalnih računa mesečno, ručni unos može biti dovoljno brz, naročito kada su dobavljači poznati. Kod 30 do 150 urednih računa, QR čitač često smanjuje prepisivanje PFR-a, datuma i iznosa. Kada agencija radi sa više klijenata, većim brojem dobavljača, fotografijama, izbledelim termalnim papirom i različitim formatima, vrednost prelazi sa samog očitavanja na standardizaciju izlaza: isti skup kolona, isti redosled, jasni izuzeci i trag do originala.

Koja polja treba izvući pre uvoza u KPR ili KUF

Popunjavanje KPR iz fiskalnih računa treba posmatrati kao pripremu podataka za knjiženje, ne kao puko prepisivanje ukupnog iznosa. Slika računa dokazuje izvor, ali KPR ili KUF traže podatke koji mogu da se sortiraju, provere i povežu sa partnerom, kontom i PDV evidencijom.

Pravna evidencija i radni import fajl nisu ista stvar, ali tabela treba da nosi dovoljno podataka da knjigovođa može da proveri prethodni porez i poveže račun sa originalom. Zato je korisno osloniti se na zahteve za PDV evidencije iz Pravilnika o porezu na dodatu vrednost, a zatim kolone prilagoditi softveru i šifarnicima agencije.

Radna tabela za knjigovođu najčešće treba da ima ove kolone:

• klijent ili poslovna jedinica kojoj račun pripada;
• dobavljač i PIB dobavljača;
• datum računa ili datum prometa, prema načinu na koji agencija vodi evidenciju;
• PFR identifikator ili broj računa;
• osnovica, PDV i ukupan iznos;
• način plaćanja, ako je relevantan za proveru kartica, gotovine ili troškova zaposlenih;
• kategorija troška ili predlog konta;
• status PIB-a kupca;
• izvorni fajl i strana;
• napomena za proveru.

KUF je u praksi često softverski ili stariji naziv koji knjigovođe i dalje koriste za istu operativnu potrebu: ulazni dokument treba pretvoriti u red koji se može proveriti pre knjiženja. Zato je KUF iz fiskalnih računa Excel tema ista u suštini kao i priprema KPR-a, samo se nazivi kolona, šifre i import pravila razlikuju od paketa do paketa.

PIB kupca je posebno važan kao kontrola, jer određuje da li račun uopšte može da se tretira kao poslovni dokument za određeni PDV tretman. U batch obradi on je kontrolni signal: red sa urednim PIB-om kupca ide u dalju proveru, red bez PIB-a ili sa pogrešnim PIB-om ide u izuzetke. Za poresku stranu teme bolje je koristiti poseban vodič za pravila za fiskalni račun sa PIB-om kupca, umesto da se ta pravila mešaju sa tehnikom batch obrade.

Čist import fajl ne treba da trpi sve probleme. Ako je QR nečitljiv, ako je PFR odsečen na fotografiji, ako je račun refundacija, ako se osnovica i PDV ne slažu ili ako se ne vidi kome račun pripada, takav red treba da ode u posebnu tabelu izuzetaka. To usporava prvi prolaz, ali štedi vreme kod knjiženja, jer knjigovođa ne mora da zaustavlja uvoz zbog dokumenata koji ionako traže ručnu odluku.

QR kod i TaxCore JSON rade samo kada je ulaz dovoljno čitljiv

QR kod fiskalnog računa za knjiženje je najbolji ulaz kada je račun nov, ceo i jasno fotografisan ili skeniran. U sistemu e-fiskalizacije QR kod vodi ka verifikacionom linku, a taj link može da vrati strukturisane podatke o računu. Za agenciju to znači manje prepisivanja i manji rizik da se pogreši PFR broj, datum ili iznos.

Zvanična dokumentacija je korisna jer potvrđuje šta se tehnički može dobiti iz QR putanje. Poreska uprava objašnjava da se ispravnost fiskalnog računa može proveriti GET pozivom na URL iz QR koda uz zaglavlje Accept: application/json, bez autentifikacije, a TaxCore odgovor sadrži podatke o računu, žurnal i status provere, prema dokumentu TaxCore uputstvo za skeniranje računa sa JSON odgovorom. To je jak temelj za automatizaciju kada je QR čitljiv i kada agencija može da sačuva vezu između odgovora i izvornog dokumenta.

Ali QR JSON nije ceo knjigovodstveni tok obrade. Račun može stići kao loša fotografija iz Viber ili WhatsApp poruke, termalni papir može izbledeti, QR može biti savijen ili odsečen, a klijent može poslati PDF sa više računa i dodatnim napomenama. Stariji printovi i dokumenti iz prelaznih perioda mogu imati ćirilicu, latinicu ili mešovite oznake koje knjigovođa i dalje mora da razume u kontekstu troška.

Zbog toga obrada termalnih fiskalnih računa za knjigovodstvo obično traži kombinaciju metoda. QR je odličan za validaciju i osnovne podatke kada radi. OCR ili AI su korisni kada treba pročitati ostatak dokumenta, izdvojiti podatke iz fotografije, povezati red sa izvornim fajlom, klasifikovati trošak ili izvući podatke u tačno onaj Excel raspored koji agencija koristi. Ručna provera ostaje potrebna za izuzetke: nečitljiv QR, pogrešan klijent, nejasan PIB kupca, refundacija ili račun koji se ne uklapa u standardni PDV tretman.

---

Kako izabrati između ručnog unosa, QR čitača, ERP uvoza i AI ekstrakcije

Najbolja metoda nije ista za agenciju koja dobije 18 računa od jednog klijenta i za agenciju koja krajem meseca primi 600 fotografija, skenova i PDF-ova od nekoliko PDV obveznika. Mesečna obrada fiskalnih računa knjigovodstvo opterećuje na dva mesta: prvo kroz čitanje podataka, zatim kroz standardizaciju redova za pregled i uvoz.

Ručni unos je racionalan kada je obim mali i kada knjigovođa već zna dobavljače. Kod manje od 30 računa mesečno po klijentu, vreme podešavanja posebnog toka obrade može biti veće od koristi. Rizik raste kada se isti posao ponavlja za više klijenata: pogrešan datum, pogrešan PFR, zamena osnovice i ukupnog iznosa ili previđen status PIB-a kupca.

QR čitač pomaže kada su računi fizički dostupni i QR kodovi uredni. Dobar je za srednji obim, posebno kada se isti tip računa ponavlja. Njegova granica je organizaciona, ne samo tehnička: čitač ne zna kom klijentu račun pripada, ne rešava loše fotografije, ne klasifikuje trošak i ne pravi nužno tabelu u rasporedu koji agencija koristi za import.

ERP ili aplikativni uvoz ima najviše smisla kada agencija već radi u paketu koji podržava očitavanje fiskalnih računa i kada klijenti šalju podatke u očekivanom obliku. Ako su svi klijenti u istom sistemu, to može biti najkraći put. Ako svaki klijent šalje drugačije fajlove ili agencija mora prvo da napravi kontrolnu Excel tabelu, tok unutar ERP-a obično treba dopuniti pripremom podataka van sistema.

AI ekstrakcija ima smisla kada ulaz nije uredan: slike, skenovi, PDF-ovi, više računa u jednom fajlu, različit kvalitet štampe i potreba da se isti skup kolona dobije za više klijenata. U tom kontekstu AI ekstrakcija računa u strukturisan Excel nije zamena za knjigovodstvenu odluku, već način da se iz mešovitog batch-a dobije Excel, CSV ili JSON za pregled.

Invoice Data Extraction se u takav tok uklapa kao alat za pripremu podataka: korisnik uploaduje PDF, JPG ili PNG fajlove, promptom opiše koje kolone želi i preuzima strukturisan Excel, CSV ili JSON. Platforma podržava velike batch-eve do 6.000 fajlova i čuva referencu na izvorni fajl i stranu u izlazu, što je korisno kada knjigovođa mora da proveri red pre uvoza. To ne znači direktno knjiženje u Pantheon, Calculus ili Minimax, već pripremu kontrolisanog fajla koji agencija mapira prema svom softveru.

Batch proces za agenciju sa više klijenata mora da razdvoji čiste redove od izuzetaka

Kod jednog klijenta greška je obično vidljiva. Kod više klijenata, ista greška može proći kroz import i tek kasnije se pojaviti kao pogrešan trošak, pogrešan partner ili račun bez prava na odbitak prethodnog poreza. Zato batch obrada mora da počne odvajanjem klijenata pre ekstrakcije, ne posle nje.

Praktičan redosled je jednostavan. Svaki klijent dobija svoj folder ili oznaku batch-a. Originalni fajlovi ostaju sačuvani pod nazivom koji ne zavisi samo od rednog broja, već pomaže kasniju proveru: klijent, mesec, izvor ili osoba koja je poslala dokument. Ako PDF sadrži više računa, izlazni red treba da nosi referencu na stranu. Ako je ulaz fotografija, treba sačuvati naziv slike, jer će knjigovođa možda morati da otvori baš taj original.

Posle ekstrakcije postoje dve tabele, ne jedna. Prva je clean import fajl, sa redovima koji su spremni za pregled i mapiranje. Druga je tabela izuzetaka. U nju idu računi sa nečitljivim QR kodom, fotografije bez celog računa, izbledeli termalni papir, nejasan PFR, nedostajući PIB kupca, sumnjiva PDV matematika, duplikati i Promet Refundacija zapisi koji traže posebno tretiranje.

Ovo razdvajanje štiti agenciju od najskuplje greške: da se problematičan red na silu ubaci u KPR ili KUF samo zato što se nalazi u istom fajlu kao i čisti računi. Izuzetak treba da nosi razlog, preporučenu akciju i izvorni fajl. Na primer: tražiti bolju fotografiju, proveriti PIB sa klijentom, ručno očitati PFR, proveriti da li refundacija poništava raniji račun ili odlučiti da se trošak ne knjiži kao prethodni porez.

Ćirilica i latinica su još jedan praktičan razlog za kontrolnu tabelu. Kod starijih printova ili lošeg OCR-a naziv dobavljača može biti prepoznat u pogrešnom pismu ili sa greškama u slovima. Za sam import je važnije da partner bude usklađen sa šifarnikom nego da je svaki karakter savršeno prenet iz slike. Zato je dobro držati posebno polje za izvorni tekst, a posebno polje za normalizovanog dobavljača koji se koristi u softveru.

Uvoz u Pantheon, Calculus, Minimax i druge pakete zavisi od mapiranja kolona

Prebacivanje fiskalnih računa u Pantheon, Calculus, Minimax, SOFTEK, Kibernetika, Profit Soft ili klijentski Excel šablon nije jedan univerzalni format. Svaki paket ima sopstvena polja, očekivani redosled, način prepoznavanja partnera, pravila za datume, decimalne separatore i šifre troškova. Čak i kada dva klijenta koriste isti softver, ne moraju imati isti kontni plan, iste šifre dobavljača ili isti način razvrstavanja troškova.

Zato je najstabilniji pristup da agencija prvo napravi normalizovanu radnu tabelu, a tek onda eksport za konkretan softver. Radna tabela može imati šire kolone: dobavljač, PIB dobavljača, PFR, datum, osnovica, PDV, ukupno, PIB kupca, kategorija, napomena, izvorni fajl. Import fajl zatim uzima samo ono što paket očekuje, u redosledu koji paket traži.

Kod mapiranja treba proveriti najmanje četiri stvari. Prvo, datumi moraju biti u formatu koji softver prihvata. Drugo, iznosi moraju koristiti odgovarajući decimalni separator i biti brojevi, ne tekst. Treće, dobavljač treba da se poveže sa postojećom šifrom partnera gde god je moguće. Četvrto, kategorija troška ili konto ne smeju biti automatski preuzeti bez provere ako klijent ima specifična pravila.

Ovakav pristup pomaže i kada agencija koristi više alata. Jedan klijent može tražiti CSV za svoj paket, drugi Excel šablon, treći samo preglednu tabelu za odobrenje troškova. Normalizovana tabela ostaje zajednički radni sloj, a import varijante se prave iz nje.

Ako vam treba širi tehnički primer izdvajanja podataka iz srpskih fiskalnih računa u tabelu, postoji i engleski vodič za izvoz srpskih fiskalnih računa u Excel. Za paralelni kanal ulaznih dokumenata u KUF-u — e-fakture koje stižu kroz Sistem elektronskih faktura — korisno je odvojeno pogledati obradu primljenih e-faktura sa SEF-a uz rok od 15+5 dana za prihvatanje ili odbijanje, jer SEF tok ima drugačija pravila od fiskalnih računa. Ovaj srpski vodič ostaje fokusiran na agencijski KPR/KUF tok: više klijenata, mesečni batch, kontrola izuzetaka i priprema podataka za softver koji već koristite.

---

Završna kontrola pre knjiženja čuva prethodni porez i trag do originala

Pre nego što redovi uđu u KPR ili KUF, knjigovođa treba da proveri podatke koji utiču na knjiženje i prethodni porez. Redosled provere je važan jer prvo uklanja greške koje mogu pomešati dokumente, zatim greške koje utiču na PDV.

Provera treba da obuhvati:

• klijenta kojem račun pripada;
• dobavljača i PIB dobavljača;
• datum računa ili prometa;
• PFR identifikator ili verifikacioni link;
• PIB kupca i njegov status;
• osnovicu, PDV i ukupan iznos;
• status refundacije;
• kategoriju troška ili predlog konta;
• izvorni fajl i stranu.

PDV matematiku treba proveriti pre knjiženja, naročito kada račun ima refundaciju, kada se plaćanje vezuje za karticu zaposlenog, kada se trošak ne priznaje za odbitak prethodnog poreza ili kada OCR pomeša osnovicu i ukupan iznos. Kod standardne stope od 20% greška često izgleda mala u jednom redu, ali postaje vidljiva kada se sabere ceo mesečni batch. Ako se isti pripremni fajl koristi i za poresku prijavu, posebno proverite prenos primljenih faktura iz KPR u POPDV pre zaključivanja perioda.

Duplikati su poseban rizik. Isti fiskalni račun može stići kao papir u koverti, fotografija iz telefona i PDF koji je klijent naknadno poslao. Zbog toga PFR identifikator, verifikacioni link i ukupan iznos treba koristiti kao signale za proveru duplikata pre uvoza. Ako softver nema takvu proveru u import koraku, bolje je uraditi je u Excelu ili u pripremnoj tabeli.

Izuzetke ne treba gurati u čist fajl samo da bi batch bio završen. Račun bez jasnog PIB-a kupca, nečitljiv PFR, loša fotografija ili sumnjiva refundacija treba da ostane u tabeli za pitanje klijentu ili dodatnu proveru. Brz import ima smisla samo ako posle njega ostaje pouzdan trag: koji je račun knjižen, iz kog originala, za kog klijenta i na osnovu koje kontrole.