Naposledy aktualizované: 2026-05-13
Schvaľovací proces v účtovníctve: kompletný sprievodca 2026
Ako nastaviť schvaľovací proces faktúr v účtovníckej kancelárii. Pravidlá, lehoty, eskalácie, FAQ a checklist na stiahnutie.
Čo sa v článku dozviete
- Štyri povinné súčasti každého schvaľovacieho procesu
- Typické zlyhania ručného schvaľovania e-mailom a chatom
- Rozdiel medzi pravidlovým systémom a ad-hoc smerovaním
- Reálny scenár faktúry nad 50 000 EUR od prijatia po schválenie
- Čo SmartDocto v tejto oblasti skutočne vie a čo nie
Účtovnícke kancelárie schvaľujú faktúry cez vlákna preposlaných e-mailov, snímky z WhatsApp a verbálny súhlas konateľa, a potom na konci roka strávia hodiny tým, aby ten istý dôkaz znovu poskladali pre audítora. Práca je neviditeľná, kým niečo neprasknie: zmeškaná splatnosť, upomienka od dodávateľa alebo audítor, ktorý sa pýta, kto presne v marci schválil faktúru za 80 000 EUR. Schvaľovací proces je pravidlami riadený systém, ktorý určuje, kto schvaľuje, v akom poradí, s akou lehotou a čo sa stane, keď lehota uplynie.
Čo je schvaľovací proces v účtovníctve?
Schvaľovací proces dokumentov je pravidlami riadený systém, ktorý vedie dokument od príchodu až po zaznamenané záväzné rozhodnutie (schválené, zamietnuté alebo vrátené na opravu). Nahrádza náhodné posielanie cez e-mail a chat za explicitné a auditovateľné pravidlá. Každý workflow má štyri povinné komponenty.
Spúšťač
Podmienka, ktorá zapne celý tok. Typicky kombinácia typu dokumentu a hodnotového prahu alebo podmienky na pole (napríklad faktúry od dodávateľa nad 50 000 EUR). Bez explicitného spúšťača systém nedokáže rozhodnúť, či dokument vôbec potrebuje schválenie.
Pravidlo smerovania
Pravidlo, ktoré určuje, kto požiadavku dostane. Smerovanie priradí dokument k jednému alebo viacerým schvaľovateľom, voliteľne podľa hodnotových pásiem, nákladových stredísk alebo skupín dodávateľov. Dobré pravidlá smerovania sú deterministické: rovnaký vstup vždy vedie k rovnakému zoznamu schvaľovateľov.
Lehota a pripomienky
Každá požiadavka má lehotu (kedy sa očakáva rozhodnutie) a kadenciu pripomienok (kedy je schvaľovateľ upozornený). Pripomienky sa konfigurujú na úrovni pravidla, typicky každých 24 hodín do stanoveného maxima, potom prestanú a požiadavka čaká na eskaláciu.
Eskalačná cesta
Čo sa stane, keď sa blíži lehota a poverený schvaľovateľ nekonal. Definovaný eskalačný cieľ prevezme požiadavku, aby ostala vždy v pohybe. Dobré systémy stavajú eskaláciu ako ľudské preradenie, nie ako tiché automatické schválenie.
Prečo ručné schvaľovanie zlyháva
Schvaľovanie cez e-mail a chat funguje pri malom objeme a potichu sa rúca, ako objem rastie. Nižšie je šesť typických zlyhaní, ktoré finančné tímy hlásia najčastejšie, keď prechádzajú z ručného procesu na pravidlami riadený.
Žiadna auditná stopa
Snímky z WhatsApp a preposielané e-maily nie sú trvalý účtovný dôkaz. Keď audítor položí otázku, kto a kedy schválil konkrétnu faktúru, odpoveď poskladaná z pamäte sa nedá obhájiť a história odchádza zo spoločnosti spolu so zamestnancom.
Jeden bod zlyhania
Keď ide jediná osoba, ktorá schvaľuje faktúry nad daný limit, na dvojtýždňovú dovolenku, rad sa zastaví. Neexistuje automatický záskok, splatnosti začnú meškať a nikoho to neupozorní, kým sa neozve dodávateľ.
Zmeškané splatnosti
Bez lehoty viazanej na konkrétnu požiadavku faktúry plávajú v osobných schránkach, kým si dodávateľ nezačne pýtať peniaze. Neskoré platby spúšťajú sankcie podľa pravidiel EÚ o oneskorených platbách a tieto náklady sa pritom málokedy spätne pripíšu schvaľovaciemu procesu.
Nekonzistentné pravidlá
Bez písomne zachyteného súboru pravidiel celá politika žije v hlave jedného finančného manažéra. Limit, od ktorého schvaľuje konateľ, alebo pravidlo na schválenie naprieč strediskami sa líši podľa toho, koho sa spýtate, a noví ľudia v tíme sa neformálne pravidlá učia týždne.
Bottleneck na konci mesiaca
Ručné schvaľovanie sa škáluje lineárne s objemom. Pri uzávierke, keď objem faktúr stúpa a účtovné zápisy musia byť zaúčtované v termíne, sa stáva schvaľovací rad obmedzujúcim prvkom. Tím pracuje do noci a chybovosť rastie.
Nulový prehľad o lehotách
Finančný manažér, ktorý chce vedieť, koľko faktúr je práve neschválených a ako dlho už čakajú, nemá centrálny pohľad. Informácie sedia v osobných schránkach, takže úzke miesta sú viditeľné až vtedy, keď spôsobia škodu.
Ručné vs. pravidlami riadené schvaľovanie
Tabuľka nižšie porovnáva typický e-mailovo-chatový proces s pravidlami riadeným workflow. Každý riadok zodpovedá skutočným schopnostiam, ktoré SmartDocto v produkcii má; riadky, ktoré by produkt nadhodnocovali, sme z tabuľky odstránili.
Ručne (e-mail/chat)
-
Spúšťač
Človek sa rozhodne dokument preposlať.
-
Smerovanie
Kto je práve online alebo na koho si odosielateľ spomenie.
-
Lehota
Implicitná, často odvodená od urgencie dodávateľa.
-
Auditná stopa
Čiastočný. E-mailový archív plus útržky z chatu, ťažko rekonštruovateľné.
-
Eskalácia
Ručné upomínanie zo strany zadávateľa, obvykle až po sťažnosti dodávateľa.
-
Externí účastníci
Preposlať e-mail a dúfať, že príde odpoveď.
Pravidlami riadený workflow
-
Spúšťač
Typ dokumentu a podmienky na poliach smerujú automaticky.
-
Smerovanie
Definovaný súbor pravidiel na pravidlo spracovania, deterministický pre každý dokument.
-
Lehota
Explicitný dueAt s konfigurovateľnou kadenciou pripomienok.
-
Auditná stopa
Záznam rozhodnutí na požiadavku s akciou, používateľom, časom a dôvodom.
-
Eskalácia
Automatické preradenie na nakonfigurovaný eskalačný cieľ.
-
Externí účastníci
Vyhradená rola externého schvaľovateľa s plnohodnotným používateľským účtom.
Ako schvaľovanie rieši SmartDocto
SmartDocto je AI platforma pre účtovnícke firmy a finančné tímy v EÚ. Schvaľovací systém rozhoduje, kto posudzuje každý dokument, v akej lehote a čo sa stane pri jej uplynutí. Schopnosti nižšie sú overené proti dátovej schéme produktu.
Základ
Jeden súbor pravidiel na pravidlo spracovania
Každé pravidlo (šablóna × AI model) má práve jeden schvaľovací súbor. Schéma to vynucuje unikátnou väzbou, smerovanie zostane deterministické.
GATE validácia
Konfigurovateľné podmienky automaticky zamietnu dokument pri porušení biznisových pravidiel (chýbajúce IČ DPH, dodávateľ mimo zoznamu). GATE vie iba zamietnuť, nikdy auto-schváliť.
Kadencia pripomienok
Konfigurovateľný interval (1 až 720 h, predvolene 24) a maximálny počet pripomienok (0 až 10, predvolene 3). Dá sa vypnúť.
Eskalačný cieľ s tichým záskokom
Pri zmeškaní lehoty sa požiadavka preradí na eskalačný cieľ. Ak nie je nastavený, padne na prvého dostupného Vlastníka, Administrátora alebo Schvaľovateľa. Požiadavky nikdy nevisia.
Pokročilé akcie
Pauza AWAITING_INFO
Schvaľovateľ požiadavku pozastaví a žiada zadávateľa o doplnenie. Pôvodná lehota sa uloží do originalDueAt, workflow pokračuje po odpovedi. Pauza má vlastný časový limit.
Vrátenie na doplnenie
Schvaľovateľ vráti dokument zadávateľovi s povinným dôvodom (vynútené na úrovni API). Stav SENT_BACK, história pokračuje bez reštartu.
Delegovanie
Aktuálne poverený schvaľovateľ dobrovoľne odovzdá požiadavku inému (akcia DELEGATED). Manuálne, na rozdiel od eskalácie, ktorá je automatická. Pôvodný schvaľovateľ zostáva v histórii.
Paralelní viacerí schvaľovatelia
Viacero podpravidiel v jednom súbore vytvorí paralelné požiadavky. Typicky: nezávislé schválenie vedúcim a vlastníkom strediska. Sekvenčné viacstupňové sa rieši samostatnými pravidlami.
Externí schvaľovatelia s plnohodnotnými účtami
Rola EXTERNAL_APPROVER umožňuje klientom a externým poradcom schvaľovať cez tímovú pozvánku. Plnohodnotné účty, nie jednorazové odkazy, auditná stopa drží trvalú identitu.
- Žiadny prevod vlastníctva schvaľovania mimo delegovania (iba aktuálny schvaľovateľ môže požiadavku odovzdať).
- Žiadne automatické schválenie na základe skóre spoľahlivosti AI.
- Žiadne sekvenčné N-stupňové schvaľovanie v rámci jedného súboru pravidiel.
Príklad reálneho workflow
Nasledujúci priechod používa generické hodnoty, ktoré zodpovedajú reálnemu správaniu SmartDocto. Scenár je jedna faktúra od dodávateľa, ktorá príde e-mailom, narazí na jedno pravidlo spracovania a prejde celým schvaľovacím procesom od začiatku po koniec.
-
01
Dodávateľ pošle faktúru e-mailom
Dodávateľ pošle faktúru na adresu fakturacia@priklad-firma.com, ktorú monitoruje kanál EMAIL. SmartDocto stiahne prílohu, spustí antivírusovú kontrolu a zaradí ju do spracovania.
-
02
Vyťažovanie podľa zhodnej šablóny
Dokument je identifikovaný ako dodávateľská faktúra a vyťažený podľa nakonfigurovanej šablóny. Hlavičkové polia a riadky faktúry sú extrahované so skóre spoľahlivosti na úrovni polí.
-
03
Pravidlo spracovania sa zhoduje a spúšťa súbor pravidiel
Pravidlo pre dodávateľské faktúry sa zhoduje a automaticky sa načíta jeho jediný schvaľovací súbor pravidiel. Unikátna väzba zabraňuje akejkoľvek nejednoznačnosti o tom, ktorý súbor sa použije.
-
04
GATE validácia prejde
GATE validácie bežia ešte pred vytvorením požiadavky. Skontroluje sa IČ DPH oproti zoznamu dodávateľov a suma faktúry oproti limitu pre dodávateľa. Neúspešná GATE by namiesto schválenia spustila automatické zamietnutie.
-
05
Vytvorí sa schvaľovacia požiadavka s lehotami
Požiadavka sa vytvorí s vlastníkom nákladového strediska ako schvaľovateľom, dueAt na T+72 hodín a escalationDueAt na T+24 hodín. Schvaľovateľ dostane upozornenie v aplikácii aj e-mailom.
-
06
Pripomienka odíde pred eskaláciou
V čase T+24 hodín, ak schvaľovateľ nekonal, sa pošle pripomienka č. 1 podľa nakonfigurovanej kadencie. Pripomienka sa opakuje v nastavenom intervale až do dosiahnutia maximálneho počtu pripomienok.
-
07
Eskalačné odovzdanie záskokovému schvaľovateľovi
Keď čas dobehne escalationDueAt bez rozhodnutia, stav prejde na ESCALATED a požiadavka sa preradí na nakonfigurovaný eskalačný cieľ. Odovzdanie je explicitné ľudské preradenie, nie automatické schválenie.
-
08
Záskokový schvaľovateľ rozhodne a beží odchádzajúca integrácia
Eskalačný cieľ skontroluje faktúru a schváli ju. Stav prejde na APPROVED, história schvaľovania sa uzavrie a dokument pokračuje do odchádzajúcej integrácie s ERP alebo účtovným systémom.
Viacúrovňové schvaľovanie
SmartDocto natívne podporuje paralelné viacero schvaľovateľov (jeden súbor, viac podpravidiel, nezávislé rozhodnutia). Sekvenčné viacstupňové schvaľovanie v jednom súbore pravidiel podporované nie je, modeluje sa cez samostatné pravidlá spracovania s prahovým smerovaním podľa hodnoty.
Paralelný viac-schvaľovateľský vzor
V rámci jedného schvaľovacieho súboru pravidiel môže ten istý dokument vyhovieť viacerým podmienkam a každá vytvorí vlastnú požiadavku. Klasický prípad je nezávislý podpis vedúceho oddelenia a vlastníka nákladového strediska. Dokument je úplne schválený, keď sa uzavrú všetky paralelné požiadavky.
Vzor prahového smerovania
Pre sekvenčné schvaľovanie podľa hodnotových pásiem nastavte samostatné pravidlá spracovania na pásmo. Faktúry pod 50 000 EUR padnú na pravidlo A a smerujú k finančnému manažérovi; faktúry od 50 000 EUR padnú na pravidlo B a smerujú ku konateľovi. Sekvencia žije v logike smerovania, nie vnútri jedného súboru pravidiel.
Lehoty a správanie eskalácie
SmartDocto pracuje s konfigurovateľnými schvaľovacími lehotami s automatickou eskaláciou, nie so zmluvnými SLA. Správanie nižšie popisuje, čo sa naozaj stane, keď lehota uplynie, vo forme konkrétnych otázok, aby boli pravidlá jednoznačné.
Čo sa stane, ak schvaľovateľ zmešká prvú pripomienku?
Pripomienka č. 2 sa pošle v nasledujúcom intervale reminderIntervalHours, až do dosiahnutia maxima maxReminders (predvolene 3). Po dosiahnutí maxima sa pripomienky zastavia a požiadavka pokračuje k svojej eskalačnej lehote bez ďalších upozornení.
Čo sa stane, keď uplynie eskalačná lehota?
Stav prejde na ESCALATED a požiadavka sa preradí na nakonfigurovaný escalationTargetUserId. Žiadne automatické schválenie sa nedeje. Eskalácia je vždy ľudské odovzdanie, ktoré sa zapíše do histórie schvaľovania s časom a príjemcom.
Čo ak nie je eskalačný cieľ nakonfigurovaný?
SmartDocto preradí požiadavku na prvého dostupného Vlastníka, Administrátora alebo Schvaľovateľa. Rovnaký záskok platí, ak je nakonfigurovaný cieľ neaktívny. Požiadavka nikdy neostáva visieť na používateľovi, ktorý ju nemôže prevziať.
Čo sa stane, keď uplynie konečná lehota dueAt bez rozhodnutia?
Stav prejde na ESCALATED. Dátový model obsahuje stav EXPIRED, ale timeout úloha ho v praxi nevyrába; timeout vždy končí eskalačným odovzdaním. EXPIRED je rezervovaný pre budúce použitie.
SmartDocto neschvaľuje dokumenty automaticky po uplynutí lehoty, ani podľa žiadneho prahu skóre spoľahlivosti AI. Každé schválenie vyžaduje výslovné rozhodnutie ľudského schvaľovateľa alebo automatické zamietnutie cez GATE pri zlyhanej podmienke. Tiché schválenie by znehodnotilo auditnú stopu.
Auditná stopa a súlad so zákonom o účtovníctve
Každá schvaľovacia požiadavka vedie plný záznam v ApprovalHistory: akcia, používateľ, predchádzajúci a nový stav, rozhodnutie, dôvod, metadáta, IP, user agent, časová pečiatka. História je iba pripojiteľná a prežije zmenu dokumentu.
To zodpovedá archivačným povinnostiam zákona o účtovníctve i požiadavkám GDPR na dohľadateľnosť spracúvania. Audítor dokáže rekonštruovať celý reťazec rozhodnutí.
Auditná stopa pokrýva dôkazné požiadavky frameworks ako ISO 27001, SOC 2 a GoBD: nemenný záznam rozhodnutí, priradenie používateľa, časované prechody stavov, dohľadateľnosť metadát.
Často kladené otázky
Ako nastaviť schvaľovací proces faktúr v účtovníckej kancelárii?
Čo sa stane, ak schvaľovateľ neschváli faktúru včas?
Môže schvaľovať faktúru externá osoba?
Aký je predvolený limit na pripomienky v SmartDocto?
Dá sa schvaľovať faktúry automaticky bez zásahu človeka?
Čo znamená AWAITING_INFO v schvaľovacom procese?
Schvaľovací proces je most medzi vyťaženými dátami a zaúčtovaným zápisom v účtovníctve. Správny návrh zachytí, kto schválil čo, s akou lehotou a s akým dôvodom, bez tichých skratiek, ktoré by podkopali auditnú stopu. Pilotná prevádzka je najrýchlejší spôsob, ako otestovať pravidlá, lehoty a eskalačné odovzdania na vašom vlastnom miešanom toku faktúr. Našli ste v článku chybu? Napíšte na info@smartdocto.com.