SEF bez portala: šta se menja kada e-fakturisanje živi unutar Vašeg ERP-a

Većina organizacija u Srbiji je rešila e-fakturisanje u užem smislu. Fakture idu napolje preko SEF-a, fakture dolaze preko SEF-a, rokovi se uglavnom poštuju. Ono što nije rešeno jeste da su portal i knjigovodstveni sistem dva različita mesta, a svaka faktura sada postoji na oba. Ta duplikacija je tiha, trajna je i tu leži najveći deo preostalog troška.

Ovaj tekst govori o tome šta se zapravo menja kada se razmena odvija unutar Business Central-a umesto u kartici pretraživača pored njega – i zašto veća dobit uopšte nije SEF, već ono što se dešava kada SEF fakture i PDF-ovi primljeni putem e-pošte završe u istom redu čekanja.

Izlazni tok, i zašto je to lakša polovina

Izlazna faktura je polovina sa kojom se većina prvo oseti sigurno. Unutar sistema, tok je kratak: faktura se kreira i knjiži u Business Central-u, šalje se na SEF u propisanom UBL formatu, bilo jednim klikom ili automatski u okviru knjiženja, a status sa SEF-a se vraća direktno na dokument fakture.

Baš taj poslednji deo je operativno bitan. Poslato, isporučeno, prihvaćeno, odbijeno, stornirano – to su stanja poslovnog odnosa, a ne samo prenosa fajla. Kada ti podaci žive na fakturi, razgovor o naplati počinje od činjenica, a ne od sećanja. Kada žive na portalu, neko mora da ode i proveri, i tvrdnja „kupac kaže da je nikada nije dobio“ pretvara se u izgubljeno popodne.

Postoji i drugi, manje očigledan efekat. Ako je slanje deo knjiženja, faktura ne može biti poslata u obliku koji se razlikuje od onog u glavnoj knjizi. Ponovno ukucavanje fakture u portal tiho dozvoljava da do kupca stigne drugačiji iznos, drugačija stopa PDV-a ili drugačiji datum dospeća od onog koji je proknjižen. Uklanjanjem tog drugog unosa uklanja se čitava ta klasa neslaganja.

Ulazni tok, gde se zapravo nalazi posao

Ulazne fakture su skuplji smer, jer svaka od njih zahteva odluku čoveka, a ta odluka ima svoj rok. Kada se obrada odvija unutar sistema, tok izgleda ovako:

1. Sistem periodično preuzima nove ulazne fakture sa SEF-a, tako da niko ne mora da pamti da to proveri.
2. Dobavljač, iznosi, PDV i datum dospeća prepoznaju se automatski, i u Business Central-u se kreira nacrt ulazne fakture.
3. Odgovorna osoba je pregleda u sistemu, po potrebi u odnosu na narudžbenicu, i odobrava je ili odbija.
4. Prihvatanje ili odbijanje na SEF-u obavlja se iz Business Central-a, bez prijavljivanja na portal.
5. Nakon odobrenja, faktura se knjiži i ulazi u plan plaćanja.

Uporedite to sa verzijom istih pet koraka na portalu: neko otvori portal, pročita fakturu, odluči da li je verodostojna – često pitajući kolegu preko četa – prihvati je na portalu, a zatim je ukuca u ERP kako bi mogla da bude plaćena i proknjižena. Faktura se čita dva puta, unosi jednom, a obrazloženje odluke o prihvatanju ne beleži se nigde.

Rokovi za prihvatanje su operativni problem, a ne pravni

Svi znaju da ulazne e-fakture moraju biti prihvaćene ili odbijene u okviru propisanog roka. Razlog zbog kojeg se rokovi propuštaju gotovo nikada nije nepoznavanje pravila. Razlog je to što je red čekanja nevidljiv svima osim jednoj ili dve osobe koje imaju pristupne podatke za portal, a te iste osobe imaju i zatvaranje kraja meseca.

Premeštanje reda čekanja u ERP menja oblik tog rizika. Fakture koje čekaju odluku predstavljaju listu u sistemu koju rukovodilac finansija može da vidi, sortira i dodeli. Odobravanje se može usmeriti prema iznosu ili vrsti troška, tako da mala faktura prevoznika ne čeka isti potpis kao veliki kapitalni izdatak. Odobrenja se mogu davati iz Teams-a, što znači da osoba koja treba da odobri ne mora da bude za stolom sa prijavom na portal. A pošto je faktura u sistemu od trenutka kada stigne, neodobrena faktura je vidljiva kao obaveza, a ne kao odsustvo bilo čega.

Revizorski trag koji dobijate besplatno

Kada se prihvatanje odvija na portalu, a knjiženje u ERP-u, veza između to dvoje je sećanje jedne osobe. Kada se oboje odvija u jednom sistemu, dobijate obično, dosadno, potpuno evidentiranje: koja faktura je kada stigla, koji nacrt je kreirala, ko ju je pregledao, u odnosu na koju narudžbenicu i koju budžetsku dimenziju, ko ju je odobrio, kada je prihvaćena na SEF-u, kada je proknjižena i kada je plaćena.

Ta evidencija vredi više od pukog osećaja usklađenosti sa propisima. Ona omogućava da se odgovori na pitanja koja bi inače ostala bez odgovora: koliko odobravanja stvarno traju, koja mesta troška sporo odobravaju, da li se hvataju duple fakture, koliki deo budžeta programa je preuzet kao obaveza, ali još nije proknjižen. Ništa od ovoga ne zahteva poseban projekat izveštavanja. Sve to proizlazi prosto iz toga što su svi događaji na jednom mestu.

Fakture koje SEF nikada ne dotakne

Ovde stiže deo koji izostaje iz većine diskusija o e-fakturisanju. Veliki deo ulaznih faktura uopšte ne stiže preko SEF-a. Strani dobavljači, hoteli, prevoznici, organizatori događaja, cloud usluge i međunarodni savezi šalju PDF putem e-pošte. Te fakture nose stvaran trošak, stvaran tretman PDV-a i stvarne rokove, i upravo su one te koje se najpouzdanije ručno prekucavaju.

Zbog toga organizacija koja je savršeno automatizovala SEF i dalje može da vodi dva ulazna procesa: automatizovan za domaće e-fakture i ručan za sve ostalo. Upravo u tom drugom procesu se gomilaju duplikati, kašnjenja u izmirenju i nezabeležene obaveze – baš zato što nema ni red čekanja ni status.

Rešenje je simetrično sa SEF-om. Organizacija definiše jednu ili više prijemnih adresa. Sistem preuzima prilog, prepoznaje dobavljača, broj fakture, datum, iznose, valutu i stavke, i kreira nacrt ulazne fakture uz koji je priložen originalni PDF. Prepoznati podaci se upoređuju sa postojećim dobavljačima i, ako postoji, sa narudžbenicom. Zatim faktura ulazi u potpuno isti tok odobravanja kao i faktura sa SEF-a.

Zašto je spajanje dva reda čekanja prava dobit

Kada oba kanala proizvode istu vrstu nacrta u istoj listi, pitanje „odakle je ova faktura stigla?“ prestaje da bude zanimljivo. Postoji jedno ulazno sanduče za fakture, jedan tok odobravanja, jedno mesto za proveru onoga što je otvoreno, i jedan revizorski trag bez obzira na kanal.

To ima tri posledice koje vredi imenovati. Kontrola postaje potpuna umesto delimična: niko ne može obavezati organizaciju na trošak preko kanala koji nema red čekanja. Izveštavanje postaje pošteno: pozicija obaveza uključuje i PDF od hotela, ne samo domaće e-fakture. A proces finansijskog tima postaje moguće naučiti, jer postoji jedan proces koji treba objasniti umesto dva sa neformalnim izuzecima.

Šta ovo ne rešava

Vredi jasno reći gde su granice. Automatsko prepoznavanje PDF-a je vrlo dobro, ali ne i nepogrešivo; loše skenirana faktura i dalje zahteva da čovek ispravi neko polje, i zato je nacrt nacrt, a ne knjiženje. Spajanje kanala ne odlučuje da li je trošak opravdan – tokovi odobravanja usmeravaju tu odluku, ne donose je umesto čoveka. I ništa od ovoga ne ukida potrebu da neko u finansijama razume tretman PDV-a; ukida potrebu da tokom perioda provodi vreme ukucavajući podatke.

Ono što zaista uklanja jeste ponovno ukucavanje, nevidljivi redovi čekanja, propušteni rokovi za prihvatanje i nesigurnost oko toga ko je šta i kada odobrio. Za većinu organizacija to je razlika između e-fakturisanja kao obaveze i e-fakturisanja kao unapređenja.