Azure, nebo Google Document AI: účet rozhodne typ dokumentu i chybné pole

Pro vytěžování českých faktur je Azure AI Document Intelligence silnějším výchozím kandidátem: jeho předpřipravený fakturační model uvádí podporu češtiny. U Google Document AI je nutné rozlišit Invoice Parser, který češtinu mezi podporovanými jazyky neuvádí, a obecnější Form Parser. Volba procesoru mění jak podobu získaných údajů, tak způsob účtování.

O výsledných nákladech proto nerozhodne jediná cena za stránku. Záleží také na počtu stran v každé faktuře a na tom, kolikrát musí člověk opravit číslo dokladu, dodavatele, datum splatnosti, daň nebo částku k úhradě. Správně rozpoznaný text ještě neznamená správně vyplněná účetní pole.

Kolik stojí stejný objem faktur

Azure účtuje předpřipravený fakturační model podle zpracovaných stran. Rozpis sazeb pro oblast US East ze srpna 2026 uvádí pro tarif S0 cenu 10 USD za 1 000 stran předpřipravených modelů, 1,50 USD za 1 000 stran samotného OCR a 30 USD za 1 000 stran vlastní extrakce. Jde o americké katalogové sazby; cena českého účtu se může lišit podle regionu, smlouvy a měny.

Ceník Google Document AI uvádí u Invoice Parseru 0,10 USD za účtovací jednotku zahrnující nejvýše deset stran jednoho dokumentu. Form Parser má základní sazbu 30 USD za 1 000 stran; samostatné OCR stojí po bezplatném měsíčním pásmu 1,50 USD za 1 000 stran. Google uvádí také slevové plány a možnost rezervované kapacity, takže tyto základní ceny nejsou univerzální nabídkou pro každý provoz.

Při uvedených sazbách vyjde model Azure na přibližně 100 USD za 10 000 stran. Pokud tento objem tvoří 10 000 jednostránkových faktur, Invoice Parser Google vyjde na 1 000 USD; při 5 000 dvoustránkových fakturách na 500 USD. Jestliže jde o 1 000 desetistránkových faktur, vyjde na 100 USD. Všechny tři varianty obsahují stejný počet stran, ale Google zaúčtuje odlišný počet jednotek. Výpočet zahrnuje jen zpracování dokumentů za uvedené základní sazby, bez daní a dalších cloudových služeb.

Jednotka Google se počítá pro každý dokument zvlášť. Dvě pětistránkové faktury tak spotřebují dvě jednotky, zatímco jedna desetistránková jen jednu. Při odhadu provozních nákladů je proto důležitý počet faktur a rozložení jejich délek, nikoli pouze součet všech stran za měsíc. Přílohy připojené k fakturám mohou tento poměr změnit podle toho, co firma skutečně odešle ke zpracování.

U formulářů už nelze bez dalšího srovnávat Invoice Parser s fakturačním modelem Azure. Google Form Parser pracuje s obecnými dvojicemi klíč–hodnota, tabulkami a zaškrtávacími poli; při uvedené základní sazbě by 10 000 stran stálo 300 USD. Vhodný protějšek na Azure závisí na požadovaných polích a struktuře formuláře. Levnější OCR může přečíst text, ale samo neurčí, která hodnota patří do konkrétního účetního pole.

Pro český doklad rozhoduje podpora konkrétního modelu

Přehled jazykové podpory Microsoftu uvádí u modelu prebuilt-invoice češtinu pro Českou republiku. To je podstatnější údaj než obecné tvrzení, že služba rozpozná české znaky: fakturační model vrací pojmenovaná pole, která účetní systém potřebuje. Deklarovaná podpora však sama neříká, jak spolehlivě model zvládne konkrétní rozvržení dokladů nebo kvalitu skenů.

Seznam procesorů Google češtinu u předpřipraveného Invoice Parseru neuvádí, zatímco u Form Parseru ano. Invoice Parser vrací mimo jiné číslo faktury, dodavatele, daň, částku a splatnost; Form Parser vytahuje obecnější strukturu formuláře. Český text tedy může být pro jeden procesor podporovaný, aniž by zvolený procesor automaticky poskytl hotové schéma fakturačních údajů.

Pro tuzemskou firmu je to rozdíl mezi dvěma navazujícími úlohami. První je přečíst obsah dokladu, druhá správně přiřadit hodnotu k významu pole a předat ji účetnímu systému. U obecného parseru může být nutné doplnit pravidla pro převod výstupu, vlastní extrakční model nebo lidské potvrzení sporných hodnot. Taková práce patří do porovnání nákladů stejně jako cena volání API.

Co skutečně ukazuje benchmark faktur

V benchmarku Businessware Technologies z března 2026 dosáhl předpřipravený fakturační model Azure výsledku 90,52 % a Google Invoice Parser 79,76 % na stejné sadě 20 faktur. Autoři porovnávali extrakci 16 fakturačních polí včetně údajů o položkách, výstupy převedli do společného schématu a modely dodatečně netrénovali. Jde o výsledek těchto konkrétních konfigurací na použité sadě, nikoli o obecnou úspěšnost všech procesorů obou služeb.

Rozdíl činí 10,76 procentního bodu, ale pro české účetnictví jej nelze převzít jako očekávaný výsledek. Testované faktury se lišily stářím, rozvržením a počtem položek; zveřejněná metodika neprokazuje, že stejně odpovídají skladbě českých přijatých faktur. Výsledek přesto nabízí užitečnější srovnání než dvě nesouvisející procenta: oba fakturační procesory zpracovaly stejné dokumenty a jejich údaje byly převedeny na stejné názvy polí.

Při posuzování vlastních faktur má smysl oddělit údaje, jejichž chyba zastaví zaúčtování, od méně významných položek. Zaměněné datum vystavení a splatnosti může vést k jinému zásahu než nepřesný popis řádku. Stejně je třeba rozlišit chybějící hodnotu, nesprávnou hodnotu a správnou hodnotu přiřazenou do špatného pole. Souhrnné skóre tyto rozdíly samo nevyjádří.

Do účtu vstupuje oprava i čekání na výsledek

Provozní náklad lze vyjádřit jako součet ceny zpracování, práce na kontrole a opravách a nákladů na navazující zpracování. V čistě podmíněném příkladu znamená jedna dodatečná ruční oprava na každých sto z 10 000 faktur sto zásahů. Při dvou minutách na zásah jde o více než tři hodiny práce. Skutečný náklad závisí na mzdě, složitosti opravy a na tom, zda chyba vyvolá i další kontrolu.

Vedle správnosti polí je pro volbu služby důležitá odezva. Dávkové zpracování mimo pracovní dobu snese jiné prodlevy než postup, při němž účetní čeká na výsledek před zaúčtováním. Srovnatelný údaj proto zahrnuje dobu od odeslání dokladu po použitelný strukturovaný výstup, včetně pomalých požadavků a případného opakování. Průměrná doba sama může zakrýt případy, které zdržují celý pracovní postup.

Azure tak dává pro české faktury rozumný výchozí bod díky deklarované jazykové podpoře fakturačního modelu, stránkovému účtování a výsledku publikovaného testu. Google může vyhovovat jinému mixu dokumentů nebo provozu, ale u českých faktur je třeba zvlášť započítat vhodnost procesoru a práci s jeho výstupem. Rozhodující je cena za správně získaná potřebná pole na skutečných dokladech firmy, nikoli nejnižší samotná sazba OCR.

Přečtěte si také:

• Zapier, nebo Power Automate: účet mění počet tvůrců, ne jen počet spuštění
• Fakturoid, nebo iDoklad: automatizace může zdvojnásobit roční účet
• Kalifornie zakázala výpověď jen podle AI, rozhodnutí musí zkontrolovat člověk