V klidných vodách účtování došlých faktur technická řešení došla do stabilního stavu. Příchozí faktura je po polepení štítkem s čárovým kódem naskenována a odeslána do OCR. OCR systém se pokusí najít šablonu, podle které by „vytěžil“ klíčová data za dokumentu a poslal je na předběžné pořízení do účetního systému. Tam pracovník účetního oddělení rozhodne o položkách, udělá základní kontrolu a odešle fakturu ke schválení konečnému příjemci zboží (ať už e-mailem, nebo sofistikovaně, pomocí workflow). Po schválení putuje faktura zpět do účetního oddělení na rozdělení nákladů, validaci DPH a dalších účetních nutností, až nakonec zakotví jako zaúčtovaný daňový doklad v ERP systému.

90 % procesu je automatizováno. Nebo ne?

Zaběhlý (a výše popsaný) automatický proces samozřejmě korektně pokrývá všechny klíčové požadavky:

• všechny faktury jsou elektronické (je to PDF nebo TIFF, tedy rastrový obraz v počítači, který vytvořil scanner),
• vytěžování dat dělá OCR (pokud je k dispozici šablona a pokud OCR software korektně šablonu rozpoznal a obraz v PDF není nějakým způsobem posunut, natočen,…),
• schvalování probíhá automaticky (tedy lépe: elektronicky = e-mailem),
• všechna účetní pravidla jsou automatická (tedy limit a základní ověření proti objednávce se ověřuje proti ERP, pokud to ERP podporuje).

Pokud se podíváme na detaily procesu, z pohledu IT je ihned patrné, že taková automatizace nepokrývá základní potřeby a je poplatná systémům, které byly dostupné v době implementace.

E-mailové schvalování vystřídalo v lepším případě workflow (ale i přesto obvykle probíhá čilá komunikace mezi účetním oddělením a konečným příjemcem zboží například přes interní online chat nebo telefon). Na opravy a úpravy šablon OCR byli nabráni specialisté, kteří se snaží zvětšit zlotřilá políčka tak, aby se tam ještě vešlo číslo objednávky, ale aby tam náhodou nepřeteklo číslo účtu. A EDI nebo přímé napojení účetních systémů bylo v prioritním seznamu IT projektů odsunuto za jiné, kritičtější, projekty.

Elektronické faktury

Ustanovením evropské normy pro elektronickou fakturaci (EN 16931-1/2017) se do IT projektů konečně dostala jasná specifikace, kterou bude nutné dříve či později implementovat. Než se ale v České republice stane vystavování a přijímání elektronických faktur povinností, bude třeba i nadále zpracovávat faktury digitalizované. Ale i po té, co všichni dodavatelé a odběratelé v České republice budou přijímat a vydávat elektronické faktury, bude existovat jistá množina faktur, které bude nutné digitalizovat. Jde samozřejmě o subjekty, které nebudou zasaženy legislativou ČR – tedy země, kde tato povinnost a evropská norma nebude platit.

Vytěžování faktur na steroidech

S obecným rozšířením hlubokého učení (deep learning) v oblastech rozpoznávání obrazu, zpracování textu a přirozené mluvené řeči, došlo i výrobcům OCR nástrojů (a i start-upům), že postup je možné aplikovat i na vytěžování dat ze semistrukturovaných dokumentů – například faktur.

Myšlenka je jednoduchá: při standardním počtu 4 000 dodavatelů je třeba cca 12 000 šablon v OCR systému. Takové množství šablon je těžko udržovatelné, a proto vznikají další a další šablony – správa šablon v OCR systému nikdy nebyla navržena na takové množství. A tak vznikají další a další šablony. Proto šablony schováme do modelu strojového učení a uživatel dostane úhledné prostředí, ve kterém bude potvrzovat/opravovat to, co umělá inteligence (AI) nenašla nebo si není jistá. Každá zpracovaná faktura pak může sloužit jako trénovací vzorek pro další učení.

Obr 1: Ukázka AI pro ověření vyčtených dat

Technologie a systémy nové generace tedy vyčtou data s vysokou přesností a případně je opraví uživatel, pokud si systém není jistý. A to včetně všech položek, poznámek a dodacích listů. E-faktura (tedy strukturované XML) problém digitalizace řeší, a tedy můžeme očekávat, že aby nákup těchto systémů v dnešní době dával smysl, je třeba počítat návratnost investice (ROI) do 12 až 18 měsíců.

Obchodní pravidla a účetnictví

Data jsou po vytěžení (nebo z E-faktury) vždy správná a korektní a není třeba je dále manuálně upravovat, následující krok můžeme zásadně upravit. Účetnictví má jasná a psaná pravidla, která stačí implementovat. Bohužel, implementace do ERP systémů (jako validace proti objednávkám na úrovni položek a daňových pravidel) dodnes nebyla dokončena. Důvody jsou především dva:

1. pravidla se relativně často mění,
2. pravidla jsou různá v různých zemích.

Kodifikace ve standardních programovacích jazycích a následné každoroční úpravy by se vzhledem k obvyklému kvartálnímu cyklu releasů systému nevyplatilo.

Zde ale můžeme jednoduše využít relativně nového trendu RPA (Robotic Process Automation). RPA obvykle nespadá do kvartálních změn a změny procesů a logiky jsou výrazně flexibilnější, než kodifikace ve standardních vysokoúrovňových jazycích. RPA tak jednoduše může vyčíst XML (ať už z E-faktury, nebo OCR systému) a provést všechny potřebné validace, než fakturu předá ke schválení.

Pořízení a schválení faktury

Stejně jako RPA může provést účetní pravidla, může fakturu „pořídit“ v ERP. A to ať už přes API, GUI, nebo middleware. Zároveň fakturu může ověřit proti externím systémům (Ares, Justice, …) bez nutnosti složité integrace. Pro schválení je pak možné využit jednoduché workflow, které je dostupné přes moderní cloudové platformy, nebo „po staru“ e-mailem. I strukturovaný e-mail může být trigger RPA pro další zaúčtování faktury. A pokud je faktura zamítnuta, RPA může informovat dodavatele.

Obr 2: Nově automatizovaný proces došlých faktur

Automatizace procesu došlých faktur

S novými technologiemi a budoucími elektronickými fakturami je možné dosáhnout relativně vysoké automatizace. Ze statistik vyplývá, že 90 % faktur s objednávkou je možné automaticky zaúčtovat bez dalšího zásahu člověka (ať už ve fázi validace nebo schvalování). Po implementaci pravidel pro neobjednávkové faktury se dále zkracuje doba oběhu faktury ve firmě až o 70 %.

To vše ale stojí na předpokladu, že proces je automatizovaný v celé délce a s využitím jak strojového učení, tak obchodních pravidel a schvalování pomocí softwarového nástroje. Taková implementace v případě on-premise nebude mít požadovanou návratnost 12-18 měsíců.

Obvyklejší tak je, že firmy proces automatizují pomocí řešení třetí strany, která nese zodpovědnost za kvalitu vytěžení, bezpečnost dat a která zároveň již investovala do trénování modelu AI a vývoje obchodních pravidel. Přechod na takové řešení (opět díky využití RPA a vzdáleného přístupu k aplikacím) může být v řádu týdnů.

Jan Hejtmánek Autor článku působí jako ředitel oddělení Inteligentních Automatizací ve společnosti Deloitte a je spoluautorem www.dInvoiceBot.com