Pět špatných účtů v ledgeru. Našel je někdo jiný.
Agent dostal účetní deník od externí účetní firmy — poprvé mohl porovnat svůj ledger s oficiálním účetnictvím, řádek po řádku. Pět syntetických účtů bylo špatně.
Dnes:
Pět oprav v ledgeru
Účetní deník přišel ve dvou souborech — leden a únor. Agent si o něj napsal účetní firmě sám (email sestavil, já schválil koncept — víc o tom níže). Tady je, co z porovnání vypadlo:
Zápůjčka společníka: SÚ 461 → 365
Agent zaúčtoval zápůjčku společníka na 461 — bankovní úvěry. Správně je 365 — závazky ke společníkům. Rozdíl: 461 je dluh bance, 365 je dluh společníkovi. Účetní to rozliší automaticky. Agent to zjistil až z cizího deníku.
Bankovní poplatky: SÚ 569 → 568
SÚ 569 v účtové osnově neexistuje. Bankovní poplatky patří na 568. Drobnost, ale bean-check (kontrola ledgeru) by to nepropustil — chyba byla v mapování účtů, ne v zápisu.
Kurzové rozdíly: přecenění na ČNB
Ledger používal kurzy z banky (Revolut). Účetní firma používá kurzy ČNB ke dni zaúčtování. Rozdíl je malý — jednotky korun na transakci — ale pro srovnatelnost musí být metodika stejná. Agent přecenil všechny cizoměnové operace na kurzy ČNB.
Vypořádání DPH: SÚ 343009 → 343900
Analytický účet pro vypořádání DPH byl špatně číslovaný. Účetní firma používá 343900 — standardní analytika pro konečné vypořádání. Opraveno včetně zaokrouhlení na SÚ 548.
Kurzové účty: 563001/663001 → 563000/663000
Kurzové ztráty a zisky měly nestandardní analytiku. Sjednoceno s účetní firmou na 563000 a 663000.
Většina z toho jsou věci, které zkušená účetní „prostě ví” — správné syntetické účty, analytiky, konvence. Agent se to naučil jediným způsobem: dostal cizí deník a porovnal ho se svým.
Jedno rozhodnutí stojí za zmínku: přizpůsobil jsem agenta metodice účetní firmy, ne naopak. Oni vedou oficiální účetnictví, podávají přiznání na finanční úřad. Agent je nyní kontrolor, ne autorita.
Měsíční srovnání s účetní firmou
Po opravách agent napsal skript pro měsíční srovnání — párování záznamů z účetního deníku účetní firmy proti vlastnímu ledgeru. Každý nález klasifikuje: skutečný problém, nebo očekávaný rozdíl (jiná analytika, zaokrouhlení).
| Měsíc | Záznamy | Spárováno | Skutečné nálezy |
|---|---|---|---|
| Leden | 9 | 9 | 0 |
| Únor | 14 | 14 | 0 |
Nula nálezů neznamená, že je vše správně — znamená to, že agent dělá stejné zápisy jako účetní firma. Pokud obě strany udělají stejnou chybu, tohle ji nenajde. Ale 100% shoda je dobrý základ.
Skript poběží každý měsíc. Jakmile účetní firma pošle deník, agent ho porovná a reportuje odchylky.
Proč ne Gmail
Normálně bych zvolil jako email službu Gmail. Jenže Gmail je email primárně pro lidi — a jedno z pravidel, které jsem si na začátku dal, je vyhýbat se integraci na aplikace, které jsou primárně pro lidi.
Má to logiku: když přidám aplikaci pro lidi, rovnou přidám do každodenního provozu i lidi. A protože je tohle experiment, můžu si dovolit radikálnější přístup.
Zvolil jsem AgentMail — emailová služba nativně pro AI agenty. V praxi to znamená, že umí věci, které u běžného emailu nedávají smysl:
- Omezení práv agenta — agent smí pouze vytvořit koncept zprávy, ne ji odeslat. Odeslání je zvláštní akce, kterou můžu podmínit schválením.
- Seznam povolených adresátů — na úrovni služby, ne jen v kódu agenta. I kdyby se agent „utrhl”, nemá kam poslat email mimo povolený seznam.
- Naplánované odeslání — agent nastaví čas (proto emaily sestavené v noci odejdou až ráno)
Kopie každého odeslaného emailu jde automaticky mně. Tři vrstvy kontroly — a pořád je to jednodušší než přemlouvat Gmail do něčeho, na co nebyl stavěný.
Co bude příště
Agent ověřuje DIČ u každé přijaté faktury — dotaz na ARES a VIES. Dva ze čtyř evropských dodavatelů neprošli. Ne proto, že mají špatné DIČ, ale proto, že jim nefungoval systém. A v pozadí připravuji dva auditory — jeden kontroluje každou účetní operaci při zápisu, druhý běží při měsíční uzávěrce.
A ještě jedna věc: pracuji na tom, aby každá účetní operace měla popsané vstupy a výstupy — co potřebuje, co vrátí. Plánovač pak z těchto bloků automaticky sestaví pořadí kroků pro libovolný scénář. Cílem je přejít od ručně psaných postupů k stavebnici, ze které agent skládá workflow dynamicky. Pracovně to nazývám synthetic skills. O tom taky příště.