Kako automatizovati ponude, fakture i podsetnike za naplatu u malom biznisu

Gde ručni tok ponude i naplate najčešće puca

Mala firma često napravi ponudu u jednom dokumentu, fakturu u drugom programu, rok prati u kalendaru, a uplatu proverava u elektronskom bankarstvu. Svaki korak može biti ispravan sam za sebe, ali bez zajedničkog zapisa lako nastaju zastarela cena, pogrešan kontakt, propušten rok ili podsetnik poslat kupcu koji je već platio.

Cilj automatizacije faktura nije da što više poruka odlazi bez čoveka. Cilj je da ista potvrđena informacija prolazi kroz ceo proces, da se jasno vidi šta čeka i da automatika stane kada naiđe na izuzetak.

• prihvaćena ponuda se prepisuje u fakturu i uvodi mogućnost greške
• datum dospeća postoji na dokumentu, ali nema vlasnika sledećeg koraka
• status poslatog dokumenta meša se sa statusom stvarne uplate
• podsetnici zavise od sećanja i šalju se neujednačeno
• delimična uplata, reklamacija ili storniranje ostaju van glavne evidencije

Ponuda, predračun i faktura nisu isti poslovni status

Ponuda opisuje predloženi obim, cenu i uslove. Prihvatanje ponude jeste okidač za naredni korak, ali sistem ne treba sam da pretpostavi koji poreski ili računovodstveni dokument tada nastaje. Predračun, avansni dokument, konačna faktura, fiskalni račun i dokument kroz Sistem elektronskih faktura nemaju istu ulogu u svakoj situaciji.

Zato najpre sa računovođom odredite dokument i kanal koji važe za konkretan posao, kupca i poreski status. Ovaj vodič nije pravni ni poreski savet. Automatizacija treba da primeni potvrđeno pravilo i sačuva trag odobrenja, a ne da tumači propise umesto odgovorne osobe.

Jedan zapis od prihvaćene ponude do zatvorene uplate

Ne morate odmah kupiti ERP. Dovoljna početna verzija može biti tabela ili jednostavna aplikacija za fakturisanje u kojoj svaki posao ima stabilan interni ID i linkove ka zvaničnim dokumentima. Dokument može živeti u odgovarajućem sistemu, dok operativna evidencija pokazuje tok i naredni korak.

• ID posla, kupac i dozvoljeni kontakt za dokumenta
• verzija ponude, datum slanja, rok važenja i datum odobrenja
• broj i link fakture, datum izdavanja i datum dospeća
• iznos, valuta, poziv na broj ili druga potvrđena referenca plaćanja
• odvojeni status dokumenta, status uplate, odgovorna osoba i sledeći korak
• datum poslednje provere uplate i izvor te provere
• oznaka za delimičnu uplatu, spor, storniranje ili ručnu pauzu

Tok: od odobrene ponude do ispravne fakture

Tok počinje tek kada postoji jasno odobrenje ponude. Sistem zaključava odobrenu verziju, prenosi potvrđene podatke u nacrt fakture i dodeljuje proveru odgovornoj osobi. Čovek potvrđuje kupca, cenu, poreski tretman, rok i kanal slanja pre izdavanja dokumenta.

Po izdavanju se u operativni zapis vraćaju broj dokumenta, datum dospeća i link ka zvaničnom izvoru. Izmena cene ili obima ne prepisuje staru ponudu nevidljivo: nastaje nova verzija i novo odobrenje. Tako program za fakturisanje ubrzava rad, ali ne uklanja kontrolu nad poslovnom odlukom.

• odobrena ponuda pokreće nacrt, ne automatski konačni dokument
• obavezna polja se proveravaju pre izdavanja
• nepotpuni ili neusaglašeni podaci idu u red za ručnu proveru
• izdati dokument dobija stabilan link i ne menja se tihim prepisivanjem

Tri nivoa rešenja, od šablona do integracije

Najmanje opravdano rešenje zavisi od broja dokumenata, izuzetaka i ljudi koji učestvuju. Jedna osoba sa nekoliko faktura mesečno može dobiti veliku preglednost već standardnim šablonom, evidencijom i kalendarskim zadatkom. Veći obim opravdava program za fakturisanje sa statusima, a integracija ima smisla tek kada su pravila stabilna.

• Šablon i evidencija: ručno odobrenje, uredna polja, filter dospelih stavki i zadatak za proveru.
• Aplikacija za ponude i fakture: verzije, pretvaranje potvrđenih podataka, statusi, izvoz i ovlašćenja.
• Integracija ili custom tok: povezivanje prodaje, odgovarajućeg sistema za dokumenta i provere uplate uz nadzor, zapis greške i rezervni ručni put.

Proverite uplatu pre svakog podsetnika

Datum dospeća samo govori da je vreme za proveru; ne dokazuje da dug i dalje postoji. Pre podsetnika sistem mora da proveri uplatu u autoritativnom izvoru koji je firma odredila, na primer u potvrđenom bankarskom ili računovodstvenom zapisu, i da sačuva vreme poslednje provere.

Pre dospeća može otići samo dogovorena najava roka. Podsetnik za dospelu obavezu šalje se kada je faktura dospela, preostali iznos je veći od nule, kontakt je odobren, nema spora ili ručne pauze i isti korak već nije poslat. Kada integracija nije dovoljno pouzdana, sistem pravi zadatak čoveku sa pripremljenim nacrtom poruke.

• blaga najava roka nekoliko dana pre dospeća samo kada je takav korak dogovoren
• obaveštenje na dan dospeća sa brojem fakture, iznosom i jasnim načinom kontakta
• prvi podsetnik posle dospeća tek nakon provere otvorenog iznosa
• dalja eskalacija prema unapred odobrenom pravilu i uz ljudsku procenu
• gašenje svih budućih poruka odmah posle potvrđene pune uplate

Kada automatika mora da stane

Najvažnije pravilo automatizacije naplate je bezbedna pauza. Delimična uplata menja preostali iznos; reklamacija ili spor menja ton i vlasnika razgovora; storniranje zatvara stari dokument; pogrešan kontakt zahteva ispravku; obećani novi rok zahteva zabeleženo odobrenje.

Svaki od tih slučajeva treba da zaustavi redovne podsetnike i otvori zadatak odgovornoj osobi. Dugme ili status Ručna pauza mora biti vidljiv, a nastavak toka treba da zabeleži ko ga je i kada ponovo pokrenuo.

NBS IPS QR kod može da olakša plaćanje fakture

Narodna banka Srbije obezbeđuje Generator i Validator NBS IPS QR koda. Kada je pravilno formiran na računu ili fakturi, kupac može skeniranjem u aplikaciji mobilnog bankarstva da formira nalog sa unapred popunjenim podacima umesto da ih ručno prepisuje.

To smanjuje trenje pri plaćanju, ali QR kod nije potvrda da je uplata izvršena. Kod treba generisati prema važećoj specifikaciji i tehnički validirati; status uplate i dalje se proverava odvojeno pre zatvaranja stavke ili slanja podsetnika.

SEF dokument i potvrđena uplata nisu isti signal

Zvanični portal Sistema elektronskih faktura objavljuje aktuelna uputstva, API dokumentaciju i tehničke specifikacije. Ako konkretan poslovni slučaj pripada SEF toku, integracija može da razmenjuje dokumente i njihove statuse u granicama važeće dokumentacije i ovlašćenja.

Status dokumenta u SEF-u ne treba automatski tumačiti kao potvrdu novca na računu. Operativni tok zato odvojeno čuva status dokumenta i status uplate. Tačno pravilo za vaš poreski status, kupca i vrstu prometa potvrdite sa računovođom i aktuelnim zvaničnim izvorima.

Primer toka za malu uslužnu firmu

Posle dogovora sa kupcem, vlasnik označava tačnu verziju ponude kao odobrenu. Sistem pravi nacrt fakture sa potvrđenim podacima, a odgovorna osoba proverava dokument i izdaje ga kroz odgovarajući kanal. Operativna evidencija dobija broj fakture, rok, otvoreni iznos i datum naredne provere.

Svakog radnog dana automatizacija izdvaja dospele otvorene stavke. Za svaku najpre proverava poslednji potvrđeni status uplate. Plaćena stavka se zatvara; neusklađena ili delimična uplata ide čoveku; samo čista otvorena stavka ulazi u odobreni niz podsetnika. Odgovori kupca, reklamacija ili ručna pauza odmah zaustavljaju naredne poruke.

Kako meriti da li je proces bolji

Najpre zabeležite početnu osnovu tokom nekoliko uobičajenih nedelja, pa uporedite isti obim rada posle promene. Brža naplata može zavisiti od cene, odnosa sa kupcem, tržišta i drugih faktora; automatizacija ne garantuje rezultat, već treba da smanji administrativne greške i učini otvorene stavke vidljivim.

• medijana vremena od odobrenja ponude do izdate fakture
• broj otvorenih faktura bez vlasnika ili narednog koraka
• broj pogrešnih ili duplih podsetnika
• broj izuzetaka koji su pravilno zaustavili automatiku
• ručni minuti po ponudi i fakturi pre i posle promene
• dani od izdavanja do potvrđene pune uplate, bez pripisivanja uzroka unapred

Sačuvajte samo podatke potrebne za posao

U evidenciji držite najmanji skup podataka potreban za izdavanje dokumenta, komunikaciju i praćenje obaveze. Odredite ko vidi iznose i kontakte, koliko dugo se čuvaju radne kopije, kako se pristup ukida saradniku i kako se ispravka prenosi u sve povezane sisteme.

API ključevi, pristup bankarstvu i druge tajne ne pripadaju tabeli ili samoj fakturi. Čuvaju se u namenjenom bezbednom sistemu, sa najmanjim potrebnim ovlašćenjima i tragom promene. Za pravni osnov, rokove čuvanja i prava lica proverite važeće propise i stručni savet za svoju situaciju.

Kontrolna lista za malu prvu verziju

Dobra prva verzija ne mora biti potpuno automatska. Dovoljno je da nijedna odobrena ponuda ne nestane, da svaka faktura ima vlasnika i sledeći korak i da sistem pouzdano zna kada ne sme da pošalje poruku.

• mapirajte sadašnji put od ponude do potvrđene uplate
• sa računovođom potvrdite dokument, kanal i obavezna polja za svaki tip posla
• odredite jedan ID, izvor istine i vlasnika za svaki otvoreni posao
• odvojite status dokumenta, datum dospeća i status uplate
• uvedite pravilo provere uplate pre svakog podsetnika
• definišite delimičnu uplatu, spor, storniranje, pogrešan kontakt i ručnu pauzu
• testirajte plaćenu, neplaćenu, delimično plaćenu i spornu fakturu
• prvu nedelju odobravajte poruke ručno i uporedite evidenciju sa zvaničnim izvorima
• automatizujte slanje tek kada nijedan test ne pravi pogrešan ili dupli podsetnik