ETL Slovakia
ETL Slovakia
Dotazník – Efaktúra – smart funkcie
Workshop · v1.0

Peppol / eFaktúra —
dokončenie implementácie

Tento dotazník slúži ako pracovný dotazník pre partnerov a klientov k ďalšej fáze vývoja riešenia eFaktúry v prostredí ARVENA. Jeho cieľom je zachytiť otvorené otázky, rozhodovacie body a pripomienky tak, aby sa v záverečnej fáze implementácie na nič podstatné nezabudlo.

V spolupráci s Compacer sme úspešne ukončili fázu technickej implementácie eFaktúry/formátu Peppol a už sme schopní prijímať aj odosielať eFaktúry. Nasledujúca fáza sa preto sústreďuje už nie na samotnú technickú konektivitu, ale najmä na úpravu vizuálnej stránky používateľského prostredia (UI), workflow spracovania, schvaľovanie, rizikové skóre, fraud check a ďalšiu mieru automatizácie.

Nadväzujeme aj na doterajšie interné úvahy o workflow automatického účtovania faktúr, hybridnom režime spracovania a využití AI pri rozhodovaní.

Pri každej otázke je preto uvedená stručná AI poznámka ako pracovný návrh a zároveň priestor na výslovnú poznámku klienta alebo partnera.

Poznámka k AI návrhom

Pri každej otázke uvádzame pracovný návrh vygenerovaný AI. Nie je to finálne rozhodnutie ani právne stanovisko — slúži ako podklad na diskusiu a očakávame vaše doplnenie alebo korekciu.

Čo znamená MVP?

MVP (Minimum Viable Product) označuje funkcionalitu, ktorá je pre štart prevádzky eFaktúry nevyhnutná a mala by byť súčasťou prvej fázy nasadenia. Ostatné požiadavky je možné zaradiť do ďalšej fázy alebo riešiť neskôr podľa priorít a kapacít.

Časť 1 · 15 otázok

A. Rizikové skóre a predchádzanie fraudu

Cieľom tejto časti je rozhodnúť, ktoré kontroly sa budú vykonávať automaticky, ktoré budú iba informačné a ktoré situácie majú ovplyvniť schvaľovanie, automatické účtovanie alebo prípravu platby. Pracovným názvom výsledného používateľského výstupu je „Rizikové skóre“ s úrovňami Nízke / Stredné / Vysoké riziko.

01

Overenie IBAN voči verejným zdrojom

Má systém pri každej prijatej faktúre porovnať IBAN uvedený na doklade s bankovými účtami evidovanými pri dodávateľovi v dostupných verejných zdrojoch, napríklad prostredníctvom FinStat? Ak sa účet nezhoduje, má systém iba upozorniť používateľa, zvýšiť rizikové skóre alebo pozastaviť automatické spracovanie či prípravu platby?

Takúto kontrolu odporúčam zaradiť medzi základné ochranné mechanizmy. Nezhoda IBAN-u ešte nemusí automaticky znamenať podvod, mala by však výrazne zvýšiť riziko a pri platbe vyvolať povinné overenie zodpovednou osobou.

Predbežné rozhodnutie
Priorita
02

Zmena IBAN oproti predchádzajúcim faktúram

Má systém upozorniť aj vtedy, keď je IBAN uvedený na faktúre evidovaný vo verejných zdrojoch, ale líši sa od účtu použitého na predchádzajúcich faktúrach od rovnakého dodávateľa? Ak áno, aké obdobie alebo počet historických dokladov má systém porovnávať?

Odporúčam porovnávať minimálne posledný schválený účet a históriu za 24 mesiacov; pri dodávateľoch s nízkou frekvenciou fakturácie možno obdobie predĺžiť na 36 mesiacov. Samotná zmena môže byť legitímna, ale v kombinácii s ďalšími zmenami má mať výrazne vyššiu váhu.

Predbežné rozhodnutie
Priorita
03

Nový alebo dlhšie neaktívny dodávateľ

Má systém upozorniť, že ide pravdepodobne o nového dodávateľa, ak sa v histórii konkrétneho klienta doteraz nevyskytol? Budeme osobitne rozlišovať úplne nového dodávateľa od dodávateľa, ktorý iba dlhšie nefakturoval, a aké obdobie budeme pri tomto posúdení sledovať?

Je vhodné rozlišovať dodávateľa nového pre konkrétneho klienta, nového pre celú skupinu a dodávateľa po dlhšej neaktivite. Ako východisko odporúčam 24 mesiacov, pričom prvá faktúra alebo prvá faktúra po dlhej prestávke by mala byť spracovaná opatrnejšie.

Predbežné rozhodnutie
Priorita
04

Rizikový status registrácie DPH

Má systém pri faktúre zobraziť upozornenie, ak bol dodávateľ zaradený do zoznamu platiteľov DPH, pri ktorých nastali dôvody na zrušenie registrácie DPH? Akú závažnosť má mať tento signál a má ovplyvniť automatické účtovanie alebo platobný proces?

Tento údaj považujem za významný rizikový signál, ktorý má byť viditeľný už v základnom prehľade faktúry. Nemusí automaticky znamenať zamietnutie dokladu, ale mal by mať významný vplyv na rizikové skóre a viesť k ľudskému prevereniu.

Predbežné rozhodnutie
Priorita
05

Daňové a odvodové nedoplatky dodávateľa

Má systém zobrazovať informáciu, že dodávateľ eviduje dlhy alebo nedoplatky na daniach, sociálnom alebo zdravotnom poistení? Budeme zobrazovať aj zdroj, dátum zistenia a prípadne výšku nedoplatku?

Odporúčam tento údaj používať ako kontextový signál, nie ako samostatný dôvod na zablokovanie faktúry. Jeho význam rastie najmä vtedy, keď sa spája s ďalšími varovaniami, napríklad zmenou účtu, zhoršením finančnej situácie alebo neštandardnou fakturáciou.

Predbežné rozhodnutie
Priorita
06

Zmeny v osobe konateľa alebo spoločníka

Má systém upozorniť, ak u dodávateľa došlo v poslednom období k zmene konateľa, spoločníka alebo inej významnej osoby? Ak áno, aké obdobie budeme sledovať a má byť upozornenie silnejšie, ak sa zmena časovo prekrýva so zmenou bankového účtu alebo iných údajov?

Ako základ odporúčam sledovať obdobie 6 mesiacov a pri citlivejších prípadoch 12 mesiacov. Samotná personálna zmena je skôr doplnkovým signálom, no v kombinácii so zmenou IBAN-u, sídla alebo správania dodávateľa môže byť veľmi dôležitá.

Predbežné rozhodnutie
Priorita
07

Index daňovej spoľahlivosti

Má byť pri dodávateľovi zobrazený aj index daňovej spoľahlivosti? Budeme sledovať iba aktuálny stav, alebo aj jeho zhoršenie oproti predchádzajúcemu obdobiu?

Index má zmysel zobrazovať ako doplňujúci kontext a ako jeden zo vstupov do rizikového skóre. Zmena smerom k horšiemu môže byť pre systém dôležitejšia než samotná jednorazová hodnota, preto odporúčam ukladať aj historický stav.

Predbežné rozhodnutie
Priorita
08

Chýbajúce účtovné závierky

Má systém upozorniť, ak dodávateľ za jedno alebo viac predchádzajúcich období nezverejnil účtovnú závierku, hoci ju podľa dostupných údajov už mal mať zverejnenú? Po koľkých chýbajúcich obdobiach má upozornenie vzniknúť?

Tento údaj by som používal ako mierne varovanie, pretože absencia závierky môže mať aj legitímne vysvetlenie. Väčší význam má opakované chýbanie závierok alebo spojenie s ďalšími negatívnymi signálmi.

Predbežné rozhodnutie
Priorita
09

Vlastné rizikové skóre dodávateľa a faktúry

Má systém z dostupných externých údajov, internej histórie klienta a charakteristík konkrétnej faktúry počítať vlastné rizikové skóre? Budeme rozlišovať riziko dodávateľa, riziko konkrétnej faktúry a výslednú úroveň Nízke / Stredné / Vysoké riziko?

Vlastné rizikové skóre odporúčam zaviesť, ale musí byť vysvetliteľné a nesmie zostať iba jedným číslom bez dôvodov. Používateľ má v základnom zozname vidieť jasnú úroveň rizika a po rozkliknutí konkrétne signály, ktoré k nej viedli.

Predbežné rozhodnutie
Priorita
10

Riziko finančných ťažkostí alebo úpadku

Má systém upozorňovať na zvýšené riziko finančných ťažkostí dodávateľa, prípadne na dostupné informácie o konkurze, reštrukturalizácii, likvidácii alebo inom závažnom stave? Ako opatrne má byť takéto upozornenie formulované?

Odporúčam používať formuláciu „zvýšené riziko finančných ťažkostí“ a jasne odlíšiť od potvrdeného právneho stavu. Takéto upozornenie má byť podložené konkrétnymi dátami a pri závažných udalostiach má výrazne ovplyvniť rizikové skóre.

Predbežné rozhodnutie
Priorita
11

Neobvyklá výška faktúry alebo dodávky

Má systém pre jednotlivých dodávateľov a typy dodávok určovať bežné hodnotové rozmedzie a upozorniť, ak nová faktúra výrazne vybočuje? Budeme zohľadňovať sezónnosť, pravidelné ročné vyúčtovania a rozdielne typy plnení od toho istého dodávateľa?

Porovnanie by sa nemalo robiť iba na úrovni dodávateľa, ale podľa dodávateľa a konkrétneho typu plnenia. Odporúčam vychádzať z posledných 12 mesiacov alebo z posledných 20 podobných dokladov a pri sezónnych položkách používať dlhšiu históriu.

Predbežné rozhodnutie
Priorita
12

AI kontrola položiek a obsahu faktúry

Má AI analyzovať jednotlivé položky faktúry a upozorniť, ak sa obsah, množstvo, cena, sadzba DPH alebo charakter plnenia nezhodujú s bežnou históriou daného dodávateľa a klienta? Aké obdobie alebo počet porovnateľných faktúr budeme analyzovať?

Táto kontrola môže zachytiť zmenu, ktorú samotná hlavička faktúry neukáže. Ako východisko odporúčam 12 až 24 mesiacov alebo posledných 20 až 30 podobných dokladov, pričom výsledok má byť skôr upozornením než automatickým verdiktom.

Predbežné rozhodnutie
Priorita
13

Automatické upozornenia pri priamom účtovaní

Ak klient faktúry sám neschvaľuje alebo ich má nastavené na priamy tok do účtovníctva, má systém pri zistení problému automaticky informovať klienta e-mailom, notifikáciou alebo iným spôsobom? Má byť upozornenie vždy zobrazené aj zodpovednej osobe, ktorá faktúru účtuje alebo spracúva?

Interná zodpovedná osoba má riziko vidieť vždy. Informovanie klienta by malo byť nastaviteľné podľa úrovne rizika, typu problému a preferovaného kanála; pri vysokom riziku odporúčam aj povinné potvrdenie ďalšieho postupu a auditný záznam o doručení upozornenia.

Predbežné rozhodnutie
Priorita
14

Kontrola identifikačných údajov dodávateľa

Má systém porovnať identifikačné údaje na faktúre, najmä názov, sídlo, IČO, DIČ a IČ DPH, s údajmi evidovanými vo verejných registroch a interných databázach? Má pritom zohľadniť aj historické údaje a dátum, ku ktorému zmena nastala, aby starší doklad nebol nesprávne označený za chybný?

Túto kontrolu odporúčam zaradiť medzi základné validačné mechanizmy. Dôležité je porovnávať údaje podľa dátumu faktúry, pretože zmena sídla alebo názvu môže byť legitímna a starší doklad môže obsahovať v tom čase správne údaje.

Predbežné rozhodnutie
Priorita
15

Centrálna databáza rizikových dodávateľov a incidentov

Máme viesť spoločnú internú databázu využiteľnú naprieč klientmi, ktorá bude obsahovať verejne známe podvodné schémy, overené rizikové udalosti, opakujúce sa incidenty alebo dodávateľov vyžadujúcich zvýšenú pozornosť? Ak áno, aké pravidlá overenia, ochrany údajov a odvolania nesprávneho označenia potrebujeme?

Takáto databáza môže byť veľmi cenná, ak bude postavená na overených udalostiach a nie na neformálnych dojmoch. Odporúčam zdieľať najmä verejné alebo anonymizované rizikové signály, zaviesť schvaľovanie záznamov a možnosť ich prehodnotenia, aby sa minimalizovali falošné označenia.

Predbežné rozhodnutie
Priorita
Časť 2 · 13 otázok

B. Všeobecné produktové a procesné otázky

Táto časť sa sústreďuje na používateľské workflow, schvaľovanie, komunikáciu s klientom, párovanie s objednávkami, analytické členenie a auditnú stopu. Cieľom je nastaviť riešenie tak, aby bolo dostatočne jednoduché pre menších klientov a zároveň konfigurovateľné pre komplexnejšie organizácie.

01

Zobrazenie archívu importovaných faktúr

Budeme v rovnakom prostredí zobrazovať aj archív historicky importovaných faktúr? Ak áno, majú byť označené tagom „Importované“ a zahrnuté do predvoleného zoznamu, alebo majú byť dostupné až po zapnutí filtra či otvorení archívu?

Odporúčam zachovať plnú dohľadateľnosť, ale importované doklady nezaraďovať do predvoleného operatívneho zoznamu. Tag má byť jasne viditeľný v detaile a vo filtroch, aby si ich používateľ nezamenil s novými faktúrami určenými na spracovanie.

Predbežné rozhodnutie
Priorita
02

Počet stupňov schvaľovania

Aké schvaľovacie modely má riešenie podporovať, aby pokrylo väčšinu klientov bez zbytočnej komplikovanosti? Postačí štandardne režim bez schvaľovania, jednoúrovňové a dvojúrovňové schvaľovanie, pričom ďalšie stupne budú iba voliteľnou výnimkou?

Pre väčšinu používateľov odporúčam tri základné režimy: bez schvaľovania, jeden schvaľovateľ a dve úrovne. Viacstupňový model má byť možný iba pri osobitnej potrebe, inak môže spomaliť proces a zhoršiť používateľský komfort.

Predbežné rozhodnutie
Priorita
03

Poznámky, inštrukcie a komunikácia k faktúre

Umožníme klientom pridávať k faktúre poznámky alebo konkrétne inštrukcie pre účtovníka? Potrebujeme aj samostatné komunikačné vlákno alebo chat, a ak áno, ako zabránime tomu, aby používateľ očakával okamžitú reakciu či nepretržitú dostupnosť účtovníka?

Do prvej fázy odporúčam štruktúrované poznámky a asynchrónne otázky s jasným stavom a lehotou na reakciu. Plnohodnotný chat môže vytvárať očakávanie pohotovostného režimu, preto by mal byť samostatným rozhodnutím a nie automatickou súčasťou základného workflow.

Predbežné rozhodnutie
Priorita
04

Priamy tok do účtovníctva pri malých klientoch

Umožníme klientom, ktorí nechcú schvaľovať každú faktúru, priamy tok dokladov do účtovníctva? Ak áno, postačí upozornenie e-mailom, alebo má systém pri strednom a vysokom riziku vytvoriť výnimku, pozastaviť automatický postup a vyžiadať si zásah klienta alebo zodpovednej osoby?

Priamy tok dáva zmysel, ale samotný e-mail nemusí byť dostatočný, pretože sa dá prehliadnuť. Odporúčam, aby rizikové faktúry vznikli aj ako viditeľná úloha v systéme a pri vysokej úrovni rizika sa automatický postup dočasne zastavil.

Predbežné rozhodnutie
Priorita
05

Významnosť faktúry a povinné vyjadrenie klienta

Má systém umožniť nastaviť pravidlá, podľa ktorých sa pri vybraných faktúrach vždy vyžiada osobitná pozornosť alebo vyjadrenie klienta, aj keď klient bežne faktúry neschvaľuje? Budú sa tieto pravidlá nastavovať podľa sumy, dodávateľa, typu nákladu, rizika alebo iných kritérií?

Takúto funkciu odporúčam oddeliť od bežného schvaľovania a pomenovať ju napríklad „Vyžaduje vyjadrenie klienta“. Môže sa spúšťať podľa sumy, rizika, konkrétneho dodávateľa alebo citlivej kategórie a vytvorí výnimku bez toho, aby klient musel schvaľovať všetky doklady.

Predbežné rozhodnutie
Priorita
06

Stredisko, činnosť a zákazka

Umožníme klientom priamo pri faktúre dopĺňať alebo meniť Stredisko, Činnosť a Zákazku? Má systém v budúcnosti tieto hodnoty navrhovať pomocou AI na základe histórie, obsahu faktúry, logických súvislostí a prípadne ďalších interných dát klienta?

Editáciu odporúčam umožniť ako voliteľnú funkciu podľa klienta, pričom musí byť zrejmé, kto hodnotu zadal alebo zmenil. AI návrhy sú vhodným ďalším krokom, ale majú vyberať iba z platných hodnôt a pri neistej zhode ponechať finálne potvrdenie človeku.

Predbežné rozhodnutie
Priorita
07

Párovanie faktúry s objednávkou (PO)

Budeme už v tejto fáze podporovať priradenie prijatej faktúry k vydanej objednávke (PO)? Má ísť iba o manuálne prepojenie a evidenciu čísla objednávky, alebo aj o automatické vyhľadanie pravdepodobnej zhody?

Minimálne manuálne priradenie a evidenciu referencie odporúčam zaradiť už do základnej verzie, ak sú objednávky pre klienta relevantné. Automatické vyhľadávanie zhody môže byť ďalšou fázou, no dátový model by naň mal byť pripravený od začiatku.

Predbežné rozhodnutie
Priorita
08

Porovnanie faktúry s objednávkou

Ak je faktúra spárovaná s objednávkou, budeme porovnávať iba celkovú sumu, alebo aj dodávateľa, menu, položky, množstvá, jednotkové ceny a tolerované odchýlky? Čo sa má stať pri prekročení tolerancie?

Plnohodnotné porovnanie má význam iba vtedy, ak klient eviduje objednávky v dostatočnej kvalite. Odporúčam nastaviteľné tolerancie a jasné rozlíšenie medzi drobnou odchýlkou, ktorá sa iba označí, a závažným nesúladom, ktorý zastaví automatický postup.

Predbežné rozhodnutie
Priorita
09

Voľné tagy a klientská kategorizácia

Umožníme klientom okrem Strediska, Činnosti a Zákazky pridávať aj vlastné tagy alebo kategórie podľa ich špecifických potrieb? Budú tagy voľné, alebo bude mať klient spravovaný zoznam povolených hodnôt?

Tagy môžu byť praktické pre filtrovanie, reporting a osobitné workflow, ale úplne voľné pomenovania môžu rýchlo vytvoriť chaos. Odporúčam spravovaný zoznam klientskych tagov s možnosťou doplnenia nového tagu oprávnenou osobou.

Predbežné rozhodnutie
Priorita
10

Kontrola použitej sadzby DPH

Má systém posudzovať, či sadzba DPH uvedená na faktúre a jednotlivých položkách zodpovedá charakteru dodaného tovaru alebo služby? Má AI pri možnom nesúlade zobraziť iba soft warning, alebo v niektorých prípadoch vyžiadať povinné odborné preverenie?

Takúto kontrolu odporúčam zaviesť ako soft warning, pretože správna sadzba môže závisieť od detailov, ktoré faktúra neobsahuje. Pri výraznej alebo opakovanej nekonzistencii môže systém presmerovať doklad na daňové preverenie, nemal by však bez jasného pravidla automaticky meniť sadzbu.

Predbežné rozhodnutie
Priorita
11

Vlastné pravidlá zvýraznenia faktúr

Umožníme klientom nastaviť si dodávateľov, typy faktúr alebo vlastné podmienky, pri ktorých sa má doklad vždy zvýrazniť alebo zaradiť medzi prioritné? Aké typické scenáre chceme podporiť, napríklad strategický dodávateľ, prepojená osoba, investícia, citlivý náklad alebo suma nad limit?

Takéto pravidlá majú veľký praktický význam, ak zostanú jednoduché a vysvetliteľné. Odporúčam ponúknuť niekoľko predpripravených scenárov a zároveň obmedzenú možnosť vlastných pravidiel, aby sa systém nezaplnil protichodnými upozorneniami.

Predbežné rozhodnutie
Priorita
12

Rozsah auditnej stopy

Aké udalosti má auditná stopa evidovať nad rámec bežného prijatia, schválenia a zaúčtovania faktúry? Máme ukladať aj zmeny rizikového skóre, dôvody upozornení, verziu externých údajov, používateľské výnimky, odoslané notifikácie a zmeny účtovných alebo platobných inštrukcií?

Auditná stopa by mala zachytiť nielen kto a kedy faktúru zmenil, ale aj na základe akých údajov systém rozhodol. Osobitne odporúčam ukladať dôvody rizika, potvrdené výnimky, zmenu stavu dodávateľa, odoslané upozornenia a snapshot údajov použitých pri rozhodnutí.

Predbežné rozhodnutie
Priorita
13

Osobitné platobné inštrukcie

Má mať klient pri prehliadaní alebo schvaľovaní faktúry samostatné pole pre platobné inštrukcie, ktoré nebude splývať so všeobecnou poznámkou? Aké pokyny má podporovať, napríklad pozastaviť platbu, uhradiť len časť, zaplatiť až po splnení podmienky alebo upozorniť na dohodnutý termín?

Samostatné pole pre platobné pokyny odporúčam, pretože má iný význam a vyššiu citlivosť než bežná poznámka. Pokyn musí mať jasného autora, auditnú stopu a oprávnenia; zároveň nesmie slúžiť na nenápadnú zmenu bankového účtu bez osobitného overenia.

Predbežné rozhodnutie
Priorita

Priestor pre všeobecnú poznámku

Čokoľvek k Peppol implementácii, čo nezapadá do jednotlivých otázok.

Hotové?

Odošlite vaše odpovede – automaticky ich uložíme a spracujeme. Zároveň si môžete stiahnuť JSON, skopírovať textové zhrnutie alebo dotazník vytlačiť.

© ETL Slovakia · ARVENA · pracovný dokument, neurčené na verejnú distribúciu.