Svátek práce i pro agenty? Ještě ne, aneb 10 faktur v jednom řádku auditního záznamu je problém

Dnes je 1. května, svátek práce, a není lepší způsob, jak jej oslavit, než novinkami o agentovi, který přebírá rutinní práci člověka — konkrétně účetnictví. Při psaní mě napadá, zda přijde doba, kdy bude svátek práce i pro agenty — spíše ne, jen sváteční halucinace.

Březnová uzávěrka dopadla lépe, než jsem čekal. Přiznání k DPH, kontrolní hlášení, srovnání s externí účetní firmou, platební příkaz — všechno prošlo.

Předchozí díly: Novinky.

Dnes:

• Shrnutí kroků
• Deset faktur v jednom řádku
• Účetní agent v mobilním telefonu? Testuji nové modely
• Když faktura nezapadá do jednoduchého režimu
• Bankovní API jako samostatná stavebnice

Shrnutí kroků

• DPH+KH za březen: vlastní XML agenta se shodovalo s podanými XML, rozdíly jen v zaokrouhlení.
• Platební příkaz k DPH: agent připravil a odeslal příkaz do banky, člověk jej autorizoval.
• Březen od začátku do konce: výpisy, přijaté a vydané faktury, kurzy ČNB, kontrola zůstatků.
• Srovnání deníku: po doplnění čísel dokladů z deníku spárováno 24/24 záznamů, 0 chyb.
• Generátor DPH/KH: XML se ověřuje proti oficiálním schématům z portálu Moje daně.
• Komunikace s účetní firmou: agent zpracoval žádost účetní firmy, připravil odpovědi a stáhl doručenky.

Deset faktur v jednom řádku

Zatím nejpraktičtější problém, na který jsem narazil: agent má tendenci dělat účetní operace hromadně.

Typický příklad: dostane deset přijatých faktur a začne je zpracovávat v jednom běhu. Z pohledu běžného programování dává postup smysl — méně kroků, méně čekání, rychlejší výsledek.

Z pohledu účetnictví je postup špatný.

Ne proto, že by deset faktur neuměl zaúčtovat. Problém je v dohledatelnosti. Když se deset dokladů objeví v auditním záznamu jako jeden řádek, ztratím přesně to, kvůli čemu auditní záznam existuje: možnost později projít, co se stalo s každým konkrétním dokladem, s každou konkrétní účetní operací.

U účetnictví nechci vědět jen výsledek. Chci vědět cestu:

• jaký doklad agent četl,
• jaký účetní postup použil,
• jak rozhodl o DPH,
• jaký kurz použil,
• co zapsal do účetního deníku,
• co ověřil před uložením zápisu.

Slitý auditní záznam dělá rekonstrukci nepříjemnou. A kdo někdy dohledával chybu v účetnictví několik měsíců zpětně, ví, že „nepříjemná“ je slušné slovo.

Proto zpřísňuji pravidlo: jeden doklad, jedna účetní operace, jeden auditní záznam. Hromadné zpracování může existovat jako rámec, ale uvnitř musí zůstat jednotlivé kroky oddělené.

Právě hromadné zpracování agent sám od sebe nepochopí. Pro něj je „rychleji“ přirozený cíl. Pro účetnictví je často důležitější „dohledatelněji“.

Účetní agent v mobilním telefonu? Testuji nové modely

V posledních měsících jsem kvůli obchodní politice společnosti Anthropic začal více testovat otevřené modely, jako DeepSeek-V4 nebo Kimi-2.5. Nijak vědecky, spíše empiricky: stejný projekt, stejná dokumentace, běžný úkol.

Na radaru mám také otevřené modely, které lze spustit lokálně:

• qwen/qwen3.6-35b-a3b
• gemma-4-26b-a4b-it-mlx
• gemma-4-E2B-it-MLX-8bit — zajímá mě hlavně velikostí. Vejde se i do zařízení, kde bych účetního agenta ještě nedávno nečekal.

Zaujalo mě komunitní srovnání Gemma 4 E2B: pět modelů Gemma, deset sad podnikových úloh, zhruba 120 testů, lokální běh na Apple Silicon. Gemma 4 E2B tam vyšla na 80,4 % napříč devíti hodnotitelnými sadami — prakticky na úrovni větší Gemma 3 4B (80,8 %) a nad starší Gemma 2 2B (77,6 %). Zajímavé nejsou jen celkové body: vytěžení informací 80,2 %, klasifikace 92,9 %, volání nástrojů 80 %, vícekolový rozhovor 70 %. Slabina: navazující řetězce nástrojů selhaly u celé rodiny modelů.

Na testování připravuji malou referenční sadu ze skutečných auditních záznamů: 50–100 úloh, které už agent řešil v provozu — vytěžení dokladu, zařazení dokladu, výpočet DPH, krátké shrnutí a také situace, kdy se má zastavit a zeptat. Opus 4.7 bude hrát roli zkušené účetní: vytvoří nebo zkontroluje očekávaný výsledek a ostatní modely budu porovnávat s ním.

U jednoduchých úloh půjde měřit přesně: sedí dodavatel, částka, sazba DPH, datum a výstupní formát. U volnějších úloh nechám Opus 4.7 hodnotit přesnost, věrnost zdrojům a dodržení instrukcí.

Zvlášť mě zajímá Gemma 4 E2B: nečekám, že vyřeší hraniční DPH režimy, ale pokud spolehlivě vytěží doklad a nevymýšlí si částky, může mít v účetním agentovi své místo. Pak si dovedu představit účetního agenta v mobilu.

Když faktura nezapadá do jednoduchého režimu

V březnu se objevila zahraniční SaaS faktura, která nezapadala do jednoduchého pravidla „služba ze zahraničí = reverse charge“. Na faktuře byla uvedena daň v režimu OSS. V podobné situaci nechci, aby agent udělal sebevědomou zkratku.

Možnosti byly v zásadě tři:

1. zaúčtovat jako reverse charge,
2. zaúčtovat jako nákup s uvedenou daní,
3. požádat dodavatele o opravu faktury.

Agent k faktuře neudělal definitivní závěr. Připravil dotaz pro externí účetní firmu a popsal varianty. Chování agenta považuji za správné. Ne proto, že by problém vyřešil. Nevyřešil. Ale správně rozpoznal, že jde o místo, kde je lepší zapsat nerozhodnutý stav než vyrobit čistý, ale možná špatný účetní zápis.

V účetnictví je podobná opatrnost podstatná. Chyba často nevypadá jako chyba. Vypadá jako velmi úhledně zapsaná jistota.

U agenta proto nechci jen pravidla typu „když A, udělej B“. Chci i pravidla typu „když A vypadá jako B, ale nese znak C, zastav se a ptej se“.

Rozpoznávání podobných hranic bude podle mě jedna z nejtěžších částí celého experimentu.

Bankovní API jako samostatná stavebnice

Krátké vysvětlení pro čtenáře, kteří nejsou programátoři ani IT odborníci: bez rozhraní API k externím datům — konkrétně k datům banky — je agent jen nástroj uzavřený v bublině. Nikam se nepodívá, nic nezapíše. Bez bankovního API se účetnictví dělá ručně.

Dlouho jsem byl zákazníkem Komerční banky a Raiffeisenbank, ale kvůli agentovi jsem přešel k Fio bance. Důvod je jednoduchý: Fio banka má moderní rozhraní API, které podporuje vše, co potřebuji pro agenta:

• stáhnout výpisy a transakce v různých formátech (PDF, GPC),
• připravit platební příkaz,
• oddělit oprávnění: čtení, odeslání příkazu a schválení člověkem.

V březnu se bankovní rozhraní poprvé potkalo s praxí: agent připravil platební příkaz k DPH, vygeneroval XML, ověřil jej proti schématu a odeslal do banky. Tím jeho část práce skončila. Samotnou autorizaci jsem musel potvrdit já v internetovém bankovnictví.