Schvalovací proces v účetnictví: kompletní průvodce pro rok 2026
Jak nastavit schvalovací proces faktur v účetní firmě. Pravidla, lhůty, eskalace, zastupování. Reálné scénáře a checklist.
Co se v článku dozvíte
- Čtyři povinné součásti každého schvalovacího procesu
- Typická selhání ručního schvalování e-mailem a chatem
- Rozdíl mezi pravidlovým systémem a ad-hoc směrováním
- Reálný scénář faktury nad 50 000 Kč od přijetí ke schválení
- Co SmartDocto v této oblasti skutečně umí a co ne
Účetní firmy schvalují faktury přes vlákna přeposílaných e-mailů, screenshoty z WhatsApp a verbální souhlas v kuchyňce, a pak na konci roku tráví hodiny shromažďováním důkazů pro auditora. Práce je neviditelná do chvíle, kdy něco selže: dodavatel upomíná splatnost nebo se klient ptá, kdo přesně schválil fakturu nad 200 000 Kč v březnu.
Co je schvalovací proces v účetnictví?
Schvalovací proces je pravidlový systém, který převede dokument od příchodu k zaznamenanému závaznému rozhodnutí (schválit, zamítnout, vrátit k doplnění). Nahrazuje ad-hoc rozesílání přes e-mail nebo chat explicitními a auditovatelnými pravidly. Každý funkční schvalovací proces má čtyři povinné součásti.
Spouštěč (trigger)
Podmínka, která proces zahájí. Typicky kombinace typu dokumentu a hodnotového prahu nebo podmínky nad konkrétním polem, například dodavatelské faktury nad 50 000 Kč. Bez explicitního spouštěče systém nedokáže rozhodnout, zda dokument vůbec schvalování potřebuje.
Pravidlo směrování
Pravidlo, které určí, kdo požadavek obdrží. Směrování přiřadí dokument jednomu nebo více schvalovatelům, případně podle hodnotových pásem, nákladových středisek nebo skupin dodavatelů. Dobré pravidlo je deterministické: stejný vstup vždy vyústí ve stejný seznam schvalovatelů.
Lhůta a připomenutí
Každý požadavek má lhůtu (do kdy se očekává rozhodnutí) a kadenci připomenutí (jak často se schvalovatel upozorňuje). Připomenutí jsou konfigurovatelná na úrovni pravidlové sady, typicky každých 24 hodin do nastaveného maxima, pak se zastaví a požadavek čeká na eskalaci.
Cesta eskalace
Co se stane, když se blíží lhůta a přiřazený schvalovatel nereagoval. Definovaný cíl eskalace převezme požadavek, aby nezůstal viset bez pohybu. Dobré systémy řeší eskalaci přiřazením jinému člověku, nikoli tichým automatickým schválením.
Proč manuální schvalování selhává
Schvalování přes e-mail a chat funguje při malém objemu a tiše se rozpadá s rostoucím počtem dokladů. Šest typických selhání, která hlásí účetní firmy a finanční týmy nejčastěji.
Chybějící auditní stopa
Screenshoty z WhatsApp a přeposlané e-maily nejsou trvalým účetním důkazem. Když se auditor zeptá, kdo a kdy schválil konkrétní fakturu, odpověď z paměti se neobhájí a historie odchází z firmy spolu se zaměstnancem.
Jediný bod selhání na dovolené
Když jediný člověk, který schvaluje faktury nad daný práh, odjede na dva týdny pryč, fronta se zastaví. Není automatický zástup, splatnosti se zpožďují a tým se to dozví, až když si dodavatel stěžuje.
Promeškané splatnosti
Bez lhůty navázané na každý požadavek se faktury vznášejí v osobních schránkách, dokud dodavatel nepošle upomínku. Pozdní platba spouští úroky z prodlení, ale náklad se málokdy zpětně přičte schvalovacímu procesu.
Nekonzistentní pravidla
Bez sepsané pravidlové sady žije politika v hlavě jedné vedoucí účtárny. Práh pro schválení jednatelem i pravidlo pro mezistřediskové schválení se liší podle toho, koho se zeptáte, a nový kolega se týdny učí neformální zvyklosti.
Hrdlo lahve při uzávěrce
Manuální schvalování roste lineárně s objemem. Při měsíční uzávěrce, kdy objem faktur skokově roste a zápisy musí být zaúčtovány do termínu, se schvalovací fronta stává limitujícím faktorem. Tým zůstává přes čas a roste chybovost.
Žádný přehled o lhůtách
Vedoucí účtárny, která chce vědět, kolik faktur čeká neschválených a jak dlouho, nemá centrální pohled. Informace žije v osobních schránkách, takže úzká místa se ukážou až poté, co napáchala škodu.
Manuální versus pravidlové schvalování
Tabulka níže srovnává typický e-mailově-chatovací schvalovací proces s pravidlovým workflow. Každý řádek odráží schopnosti, které SmartDocto skutečně má v produkčním nasazení, řádky, jež by produkt přehnaně reprezentovaly, jsou vypuštěny.
Manuální (e-mail, chat)
-
Spouštěč
Někdo se rozhodne dokument přeposlat.
-
Směrování
Kdo je zrovna online nebo na koho si odesílatel vzpomene.
-
Lhůta
Nepsaná, většinou se vyvodí z urgence dodavatele.
-
Auditní stopa
Částečná. Archiv e-mailů plus útržky chatu, těžko se rekonstruuje.
-
Eskalace
Ruční dohánění zadavatelem, většinou až po stížnosti dodavatele.
-
Externí strany
Přeposlat e-mail a doufat, že odpoví.
Pravidlové workflow
-
Spouštěč
Typ dokumentu a podmínky polí směrují automaticky.
-
Směrování
Definovaná pravidlová sada pro každé pravidlo zpracování, deterministická pro každý dokument.
-
Lhůta
Explicitní termín dueAt s konfigurovatelnou kadencí připomenutí.
-
Auditní stopa
Záznam rozhodnutí pro každý požadavek s akcí, uživatelem, časem a důvodem.
-
Eskalace
Automatické přiřazení nastavenému cíli eskalace.
-
Externí strany
Vyhrazená role externího schvalovatele s plnohodnotným uživatelským účtem.
Jak schvalování řeší SmartDocto
SmartDocto je AI platforma pro účetní firmy a finanční týmy v EU. Schvalovací systém rozhoduje, kdo posuzuje každý dokument, v jaké lhůtě a co se stane při vypršení. Schopnosti níže jsou ověřené proti datovému schématu produktu.
Základ
Jedna pravidlová sada na pravidlo zpracování
Každé pravidlo (šablona × AI model) má právě jednu schvalovací sadu. Schéma to vynucuje unikátní vazbou, směrování zůstane deterministické.
GATE validace
Konfigurovatelné podmínky automaticky zamítnou dokument při porušení byznysových pravidel (chybějící DIČ, dodavatel mimo seznam). GATE umí pouze zamítnout, nikdy auto-schválit.
Kadence připomenutí
Konfigurovatelný interval (1 až 720 h, výchozí 24) a maximální počet připomenutí (0 až 10, výchozí 3). Lze vypnout.
Cíl eskalace s tichou záchranou
Při zmeškání lhůty se požadavek přiřadí cíli eskalace. Pokud není nastaven, padne na prvního dostupného Vlastníka, Administrátora nebo Schvalovatele. Požadavky nikdy nevisí.
Pokročilé akce
Pauza AWAITING_INFO
Schvalovatel požadavek pozastaví a žádá zadavatele o doplnění. Původní lhůta se uloží do originalDueAt, workflow pokračuje po odpovědi. Pauza má vlastní časový limit.
Vrácení k doplnění
Schvalovatel vrátí dokument zadavateli s povinným důvodem (vynuceno na úrovni API). Stav SENT_BACK, historie pokračuje bez restartu.
Delegování
Aktuálně přiřazený schvalovatel dobrovolně předá požadavek jinému (akce DELEGATED). Manuální, na rozdíl od eskalace která je automatická. Původní schvalovatel zůstává v historii.
Paralelní více schvalovatelů
Více podpravidel v jedné sadě vytvoří paralelní požadavky. Typicky: nezávislé schválení vedoucím a vlastníkem střediska. Sekvenční vícestupňové se řeší samostatnými pravidly.
Externí schvalovatelé s plnohodnotnými účty
Role EXTERNAL_APPROVER umožňuje klientům a externím poradcům schvalovat přes týmovou pozvánku. Plnohodnotné účty, ne jednorázové odkazy, takže auditní stopa drží trvalou identitu.
- SmartDocto neumí převod vlastnictví požadavku mimo rámec delegování, předání iniciuje vždy aktuálně přiřazený schvalovatel.
- SmartDocto neschvaluje automaticky na základě skóre spolehlivosti AI, žádná taková cesta v kódu neexistuje.
- SmartDocto nepodporuje sekvenční N-stupňový řetězec schvalovatelů v rámci jedné pravidlové sady, sekvenční je jen předání při eskalaci.
Příklad reálného workflow
Průchod používá obecné hodnoty odpovídající skutečnému chování produktu. Scénář popisuje jednu dodavatelskou fakturu nad 50 000 Kč přicházející e-mailem, která projde schvalovacím systémem od začátku do konce.
-
01
Dodavatel pošle fakturu e-mailem
Dodavatel pošle fakturu na adresu faktury@priklad-firma.cz, kterou hlídá kanál EMAIL. SmartDocto stáhne přílohu, projede ji antivirovou kontrolou a zařadí ji do fronty zpracování.
-
02
Extrakce běží proti šabloně
Dokument je rozpoznán jako dodavatelská faktura a extrahován proti nastavené šabloně. Hlavička a řádky položek se rozparsují, ke každému poli se zaznamená skóre spolehlivosti.
-
03
Pravidlo zpracování spustí pravidlovou sadu
Pravidlo pro dodavatelské faktury se shoduje a automaticky se načte jeho jediná schvalovací pravidlová sada. Unikátní vazba brání nejednoznačnosti, která sada se má použít.
-
04
GATE validace projde
GATE validace běží před založením požadavku. DIČ se kontroluje proti seznamu dodavatelů a celková částka proti limitu dodavatele. Při neúspěchu by GATE fakturu automaticky zamítla.
-
05
Požadavek se vytvoří se lhůtami
Vytvoří se požadavek s vlastníkem nákladového střediska jako schvalovatelem, dueAt na T+72 hodin a escalationDueAt na T+24 hodin. Schvalovatel obdrží oznámení v aplikaci i e-mailem.
-
06
Připomenutí se odešle před eskalací
V čase T+24 hodin bez akce schvalovatele se odešle první připomenutí podle nastavené kadence. Připomenutí se opakuje v konfigurovaném intervalu, dokud není dosaženo maximálního počtu.
-
07
Eskalace předá zástupci
Když je dosažen čas escalationDueAt bez rozhodnutí, stav přejde na ESCALATED a požadavek se přiřadí cíli eskalace. Předání je přiřazení jinému člověku, nikoli automatické schválení.
-
08
Zástupce schválí a spustí se výstupní integrace
Cíl eskalace fakturu zkontroluje a schválí. Stav přejde na APPROVED, historie schvalování se uzamkne a dokument pokračuje do výstupní integrace na ERP nebo účetní systém.
Vícestupňové schvalování
Vícestupňové schvalování může znamenat dvě různé věci. Paralelní více schvalovatelů směruje stejný dokument více lidem, kteří rozhodují nezávisle, a požadavek se uzavře, až rozhodnou všichni. Sekvenční vícestupňové směruje dokument nejprve osobě A a teprve po schválení osobou A pokračuje na osobu B. SmartDocto nativně podporuje paralelní více schvalovatelů, sekvenční vícestupňové v rámci jedné pravidlové sady podporováno není a doporučený způsob, jak ho namodelovat, jsou samostatná pravidla zpracování navázaná na prahové směrování podle hodnoty.
Vzor paralelního více schvalovatelů
V rámci jedné pravidlové sady může více podpravidel padnout na stejný dokument a každé vytvoří svůj požadavek na schválení. Klasické využití je nezávislé schválení vedoucím oddělení a vlastníkem nákladového střediska. Dokument je plně schválen, jakmile se uzavřou všechny paralelní požadavky.
Vzor prahového směrování
Pro sekvenční schvalování podle hodnotových pásem nastavte samostatná pravidla zpracování pro každé pásmo. Faktury pod 50 000 Kč se shodují s pravidlem A a směrují se na vedoucí účtárny, faktury od 50 000 Kč nahoru se shodují s pravidlem B a směrují se na jednatele. Sekvence žije ve směrovací logice, ne uvnitř jedné pravidlové sady.
Lhůty a eskalace
SmartDocto konfiguruje schvalovací lhůty, nikoli smluvní SLA. Chování níže popisuje, co se reálně stane, když lhůta uplyne, a odpovědi jsou strukturované jako konkrétní otázky, aby pravidla byla jednoznačná.
Co se stane, když schvalovatel zmešká první připomenutí?
V dalším intervalu reminderIntervalHours se odešle druhé připomenutí, a tak dále až do nastaveného maxima maxReminders (výchozí 3). Po dosažení stropu se připomenutí zastaví a požadavek pokračuje směrem k lhůtě eskalace bez dalších notifikací.
Co se stane, když uplyne lhůta eskalace?
Stav přejde na ESCALATED a požadavek se přiřadí nastavenému escalationTargetUserId. Žádné automatické schválení se nekoná. Eskalace je vždy předání jinému člověku, zaznamenané v historii schvalování s časem a příjemcem.
Co když cíl eskalace není nastaven?
SmartDocto požadavek přiřadí prvnímu dostupnému uživateli s rolí Vlastník, Administrátor nebo Schvalovatel ve firmě. Stejná záchrana se uplatní, pokud je nastavený cíl neaktivní. Požadavky nikdy nezůstanou viset na uživateli, který je nemůže přijmout.
Co se stane, když uplyne konečná lhůta dueAt bez rozhodnutí?
Stav přejde na ESCALATED. Datový model obsahuje i stav EXPIRED, ale eskalační cron ho v praxi neprodukuje, vypršení vždy vyústí v předání jinému člověku. EXPIRED je rezervován pro budoucí použití.
SmartDocto neschvaluje dokumenty automaticky, když vyprší lhůta, ani když AI skóre spolehlivosti dosáhne nějakého prahu. Každé schválení vyžaduje explicitní rozhodnutí člověka, nebo automatické zamítnutí přes GATE validaci při porušení podmínky. Tiché schválení by znehodnotilo auditní stopu.
Auditní stopa a soulad se zákonem o účetnictví
Každý schvalovací požadavek vede plný záznam v ApprovalHistory: akce, uživatel, předchozí a nový stav, rozhodnutí, důvod, metadata, IP, user agent, časové razítko. Historie je pouze přidávací a přežívá změnu dokumentu.
To pokrývá archivační povinnosti zákona č. 563/1991 Sb. o účetnictví i požadavky GDPR na dohledatelnost zpracování. Auditor dokáže rekonstruovat celý řetězec rozhodnutí.
Auditní stopa pokrývá důkazní požadavky frameworks jako ISO 27001, SOC 2 a GoBD: nemenný záznam rozhodnutí, atribuce uživatele, časované přechody stavů, dohledatelnost metadat.
Často kladené otázky
Jak nastavit schvalovací proces faktur v účetní firmě?
Co se stane, když schvalovatel neschválí fakturu včas?
Může schvalovat fakturu externí osoba, například klient?
Jakou má SmartDocto výchozí lhůtu pro schválení?
Lze automaticky schvalovat faktury bez zásahu člověka?
Co znamená stav AWAITING_INFO?
Schvalovací proces je most mezi extrahovanými daty a zaúčtovaným záznamem. Správný návrh zaznamenává kdo, co a kdy schválil, bez tichých zkratek, které by rozbily auditní stopu. Pilot je nejrychlejší cesta, jak otestovat pravidla, lhůty a eskalace proti vlastní skladbě faktur.