Povezivanje vašeg softvera sa SEF-om

Ko mora na SEF, a ko ne

Zakon o elektronskom fakturisanju u članu 3 stav 1 navodi pet situacija u kojima je izdavanje e-fakture obavezno: između dva subjekta privatnog sektora, od privatnog prema javnom sektoru, od javnog prema privatnom, između dva javna subjekta, i kada poreski punomoćnik stranog lica izdaje fakturu.

Ključna je definicija iz člana 2 tačka 3: subjekt privatnog sektora je obveznik poreza na dodatu vrednost. To praktično znači da linija ne ide po veličini firme nego po PDV-u. Paušalac koji nije u sistemu PDV-a i ne fakturiše javnom sektoru nije obveznik korišćenja SEF-a.

Postoji i kategorija dobrovoljnih korisnika iz člana 2 tačka 4 i člana 5 stavova 7 i 8: obveznici poreza na dohodak ili na dobit koji nisu ni javni ni privatni sektor u smislu zakona mogu da se prijave sami. Važno je da to nije odluka koju možete povući sledeće nedelje - posle prijave sistem morate koristiti u tekućoj i narednoj godini.

Tri načina da izdajete e-fakture

Pre nego što uopšte razmišljate o integraciji, vredi znati da imate tri opcije i da sve tri mogu biti ispravan izbor:

• Ručno na portalu. Besplatno, bez ijednog reda koda. Ima smisla dok je broj faktura mali i dok podaci ionako nastaju ručno.
• Preko informacionog posrednika. Član 13 zakona dozvoljava da izdavanje, slanje, prijem i čuvanje poverite posredniku koji ima saglasnost ministarstva. Brzo se uvodi, plaća se pretplata, a vi niste vlasnik integracije.
• Direktna API integracija iz vašeg sistema. Najviše posla na početku, ali fakture nastaju tamo gde podaci već postoje i niko ih ne prekucava.

Treća opcija se isplati kada vam podaci za fakturu već postoje u nekom sistemu: u proizvodnji, u magacinu, u evidenciji radnih naloga. Tada je prekucavanje na portal čist gubitak vremena i izvor grešaka. Ako vam fakture i dalje nastaju tako što neko gleda u svesku, integracija vam neće rešiti problem, nego ga automatizovati.

Kako API zaista radi

Sistem e-faktura ima javni API čiju specifikaciju Ministarstvo finansija objavljuje na portalu efaktura.gov.rs. Autentifikacija je jednostavna: svaki zahtev nosi HTTP zaglavlje ApiKey sa vrednošću koju generišete kroz svoj nalog na portalu. Nema OAuth-a, nema potpisivanja zahteva.

Produkciono okruženje je na efaktura.mfin.gov.rs, a postoje i odvojena okruženja za testiranje. Integraciju nikada ne razvijajte direktno na produkciji, jer izdata faktura ima poreske posledice.

curl -X POST \
  "https://efaktura.mfin.gov.rs/api/publicApi/sales-invoice/ubl" \
  -H "ApiKey: 00000000-0000-0000-0000-000000000000" \
  -H "Content-Type: application/xml" \
  --data-binary @faktura.xml

Format je UBL 2.1, u srpskom prilagođenju evropskog standarda EN 16931. Portal objavljuje primere XML datoteka i servis za validaciju dokumenata, i oba vredi koristiti pre nego što pošaljete prvu fakturu. Validacija pre slanja je jedina stvar koja vas deli od fakture koja je formalno izdata, a sadržinski pogrešna.

Slanje je manji deo posla

Ovde se integracije najčešće potcene. Poslati fakturu je jedan poziv. Sve ostalo je ono što čini sistem upotrebljivim:

• Praćenje statusa. Faktura prolazi kroz stanja i vaš sistem mora da zna u kom je. Postoje pozivi za pojedinačnu fakturu, za listu identifikatora i za izmene u zadatom periodu.
• Prijem ulaznih faktura. Dobavljači vama šalju fakture kroz isti sistem i njih treba povući, prikazati i proknjižiti.
• Prihvatanje i odbijanje u roku. Po članu 10 primalac iz privatnog sektora ima 15 dana da prihvati ili odbije fakturu. Ako ne reaguje, dobija novo obaveštenje, i ako ni u narednih 5 dana ne reaguje, faktura se smatra odbijenom.
• Otkazivanje i storniranje, kao zasebni pozivi sa svojim pravilima.
• Preuzimanje PDF prikaza i istorije statusa, za arhivu i za ljude koji ne čitaju XML.
• Notifikacije. Postoji poziv za pretplatu na obaveštenja, koji se u praksi mora održavati aktivnim.

Dodajte na to član 15: e-fakture u privatnom sektoru čuvaju se deset godina od isteka godine u kojoj su izdate. To je zahtev prema vašoj arhivi, ne prema SEF-u, i treba ga rešiti svesno, a ne osloniti se na to da će dokument zauvek stajati na portalu. Deset godina je duže od veka većine diskova, pa arhiva i backup ovde nisu ista stvar.

Zamke koje se vide tek u praksi

Nekoliko stvari na kojima se gubi najviše vremena, a nisu očigledne iz dokumentacije:

• Datum prometa. Ako nedostaje, sistem odbija dokument greškom InvoiceDeliveryDateMissing. Trivijalno za ispraviti, ali lako se previdi kada datum u vašoj bazi sme da bude prazan.
• Veza sa fiskalnim računima. Kada se faktura odnosi na već fiskalizovan promet, referenca na fiskalni račun ide u UBL kao AdditionalDocumentReference sa prefiksom FISR. Ako izostane, dokument pada na grešci UBLInvoiceMissingFiscalBillsOrDate.
• Poreske kategorije. Pogrešno mapiranje vaših internih šifri PDV-a na kategorije koje SEF očekuje proizvodi fakture koje prođu validaciju, a pogrešne su u poreskom smislu. Ovo je najskuplja vrsta greške jer se otkrije kasno.
• Zaokruživanje. Razlika od jednog dinara između vašeg obračuna i zbira stavki u XML-u zaustavlja dokument.

<cac:AdditionalDocumentReference>
  <cbc:ID>FISR:20250115-1107308722</cbc:ID>
</cac:AdditionalDocumentReference>

Koliko to traje i kada se ne isplati

Pošteno: samo slanje izlaznih faktura iz sistema koji već ima uredne podatke je posao od nekoliko dana. Kompletna integracija koja pokriva i prijem, statuse, rokove za prihvatanje, storniranje i arhivu redovno traje nekoliko nedelja, a najveći deo tog vremena ne odlazi na API nego na vaše podatke.

Trošak guraju četiri stvari: koliko su vam šifarnici uredni, da li faktura nastaje na jednom mestu ili na nekoliko, koliko izuzetaka ima u načinu na koji obračunavate PDV, i da li kod vas postoji neko ko može da presudi šta je ispravno kada se pojavi nejasnoća.

Ako izdajete nekoliko faktura mesečno, nemojte graditi integraciju. Portal je dovoljan i besplatan. Integracija počinje da se isplati kada prekucavanje postane posao koji neko radi svakog dana, ili kada greška u prekucavanju počne da košta više od samog kucanja.