Faktury přijaté jsou nevděčná práce. Musí být hotová správně, protože chyba se projeví až v přiznání k DPH. U e-shopu, kam chodí desítky faktur měsíčně od dodavatelů zboží, přepravců, srovnávačů a nástrojů, jsou to každý měsíc hodiny mechanického přepisování.

Tak jsem si postavil pipeline. Běží jednou denně, sama, a projde celou cestu od e-mailu až po zaúčtovaný doklad. Rozdíl je zásadní: místo přepisování dvaceti údajů z PDF do formuláře se dívám na řádek v tabulce a rozhodnu, jestli je faktura v pořádku.

Tenhle článek je popis principu, ne návod krok za krokem. Chci ukázat, z čeho se to skládá a proč zrovna takhle.

Celá cesta v jedné větě

Faktura přijde mailem do fakturační schránky → skript ji tam najde a stáhne přílohu → data z ní vytěží (ISDOC přesně, PDF pomocí AI) → zapíše řádek do Google Sheetu ke schválení → člověk schválí → skript ji přes API založí a zaúčtuje v Abra Flexi → PDF skončí v archivu na Google Drive → a nad tím vším běží aplikace, která ukazuje, co a kdy je potřeba zaplatit.

Teď po částech.

1. Sběr: fakturační schránka, která má API

První problém je banální: jak se vůbec dostat k mailům. Napojit se přímo na poštovní schránku přes IMAP jde, ale je to křehké a nepříjemné na přístupy.

Mám ale výhodu — e-shopová komunikace už stejně běží přes helpdesk (SupportBox), a ten má REST API. Faktury tedy chodí na jednu adresu, fakturace@, a ta je v helpdesku jako samostatná schránka. Skript se přes API zeptá na zprávy za poslední dny, projde je a stáhne přílohy.

Tím se to celé zjednodušilo na „zavolej endpoint a stáhni soubory“. Žádné parsování mailových hlaviček, žádné přihlašování do pošty. A jako bonus je v helpdesku pořád vidět, co se dělo — mail nezmizí do skriptu, zůstane tam, kde ho vidí i člověk.

Dvě věci jsem musel dořešit hned:

  • Duplicity. Táž faktura umí přijít dvakrát — jednou jako PDF, jednou jako ISDOC, klidně v jiném mailu. Vede se proto seznam už zpracovaných příloh a navíc se kontroluje identita dokladu (IČO dodavatele + číslo faktury), aby v tabulce nevznikl druhý řádek.
  • Faktury, které přijdou jinam. Dodavatel občas pošle fakturu na info@ nebo na osobní adresu a pipeline o ní neví. Na to je zvláštní hlídač: prohledá ostatní schránky, vyfiltruje, co vypadá jako faktura, ověří, jestli už náhodou není v účetnictví nebo ve frontě ke schválení, a zbytek nahlásí. O nalezené faktuře mi přijde notifikace do Freela.

Zvlášť řeším ještě dodavatele, kteří fakturu mailem neposílají vůbec a mají ji jen na portálu za přihlášením. Pro ně je složka na Google Drive: PDF nebo ISDOC tam nahraju ručně.

2. Vytěžení: ISDOC má vždycky přednost

Tady je věc, kterou bych zdůraznil každému, kdo staví něco podobného. Nepouštějte AI na to, co umíte přečíst přesně.

Část dodavatelů posílá kromě PDF i ISDOC — český standard elektronické faktury, což je obyčejné XML. Je v něm číslo dokladu, IČO, datumy, rozpis DPH po sazbách i celková částka, všechno strojově a jednoznačně. Přečtení takového souboru je otázka pár desítek řádků kódu, je to zdarma a nemůže se to splést.

Takže pravidlo zní: je u mailu ISDOC? Použij ISDOC. Není? Teprve pak jde do hry PDF.

AI je až druhá volba — pro případ, kdy strukturovaná data prostě neexistují.

U PDF se model podívá na fakturu a vrátí strukturovaná data: dodavatele, IČO, číslo dokladu, datum vystavení, DUZP, splatnost, variabilní symbol, rozpis DPH po sazbách a celkovou částku. Není to volný text, ale pevně daný formát, který se dá dál kontrolovat.

A hlavně: na výstup z AI se hned nasadí deterministické kontroly. Sedí součet základů a DPH na celkovou částku? Má IČO platnou kontrolní číslici? Je splatnost po datu vystavení? Co neprojde, dostane vlaječku a v tabulce se označí jako „ke kontrole“.

3. Schválení: obyčejný Google Sheet

Vytěžené faktury se sesypou do Google Sheetu — jeden řádek na fakturu, s odkazem na PDF a checkboxem Schváleno. Projdu je, odkliknu a teprve pak jdou do účetnictví.

Ve stejné tabulce je i druhý list — předpisy zaúčtování podle dodavatele. Nový dodavatel se do něj doplní automaticky s výchozím předpisem a já mu jednou provždy nastavím ten správný. Od té doby chodí jeho faktury rovnou na správné účty.

Člověk zůstává na místě, kde rozhoduje — ne na místě, kde opisuje.

4. Zaúčtování: zápis do Flexi přes API

Schválené řádky si vezme druhý skript a přes REST API je založí v Abra Flexi jako přijaté faktury — s dodavatelem, částkami, rozpisem DPH po sazbách, splatností, variabilním symbolem, předpisem zaúčtování a řádkem kontrolního hlášení. PDF se přesune do archivní složky na Drive rozdělené po měsících a odkaz zůstane u dokladu.

Zní to jako nejjednodušší krok. Ve skutečnosti tady bylo nejvíc jizev:

  • Víc sazeb DPH na jedné faktuře. Potraviny mají jinou sazbu než zbytek sortimentu, takže DPH se nedá držet jako jedno číslo — je to seznam řádků po sazbách. Kdo si to na začátku zjednoduší, přepisuje to potom celé.
  • Dobropisy. Musí jít do systému jako záporné a jako správný typ dokladu. Kladný dobropis by odpočet DPH nárokoval podruhé místo toho, aby ho opravil. Pojistka: záporná celková částka udělá dobropis i tehdy, když ho dodavatel v souboru jako dobropis vůbec neoznačí — a to se stává.
  • Cizí měna. Faktura v eurech se posílá v eurech a kurz i domácí částky si dopočítá účetní systém z kurzovního lístku. Přepočítávat si to sám je zbytečná cesta k halířovým rozdílům. Se stejnou logikou se pak musí i kontrolovat — porovnávat částku v eurech proti korunové hodnotě v systému označí každý cizoměnový doklad za chybný.

Denní shrnutí — kolik faktur přišlo, co se nepodařilo vytěžit, co čeká na schválení — chodí jako úkol do Freela. To je pointa: o všem, co selže, se musí dozvědět člověk. Automatizace, která tiše přeskočí problém, je horší než žádná.

5. A druhá polovina: kdy to vlastně mám zaplatit

Když už jsou faktury v systému správně a včas, otevře se otázka, kvůli které to celé stálo za to. Ne „jsou zaúčtované?“, ale „čím a kdy to zaplatím?“

Na to jsem si postavil druhou aplikaci. Nemá vlastní databázi — čte živě z API účetního systému:

  • Závazky — co je neuhrazené, komu a s jakou splatností, rozdělené podle toho, jak dlouho to visí (před splatností, 1–30 dní po, 31–60, 61–90, 90+).
  • Pohledávky — totéž z druhé strany, protože cash flow není o výsledovce, ale o tom, kdo komu dluží a kdy.
  • Cash flow — příjmy proti výdajům z banky a pokladny, po měsících i kumulativně.
  • Výsledovka — tržby minus náklady z fakturace, s přepínačem s DPH / bez DPH.
  • Nespárované platby a hlavní kniha — pro chvíle, kdy něco nesedí a je potřeba se dohrabat ke zdroji.

Nejhezčí drobnost je propojení obou projektů: v přehledu závazků je u faktury odkaz na její PDF. Páruje se podle variabilního symbolu proti tabulce z fakturační pipeline. Takže když se u platby zarazím, nemusím nic hledat — kliknu a mám před sebou originál faktury.

Co jsem se z toho naučil

Kdybych to měl shrnout do několika vět, které platí i mimo faktury:

  • Strukturovaná data mají přednost před AI. ISDOC je přesný a zdarma. AI nasadit až tam, kde jiná možnost není.
  • Nechte v procesu člověka na jednom místě. Ne u každého kroku — u jednoho, kde se rozhoduje. Tady je to checkbox v tabulce.
  • Chyba se nesmí ztratit. Když se něco nepodaří — faktura se nevytěží, doklad se nezaloží, příloha přijde do jiné schránky — musí mi o tom přijít zpráva. Jinak si automatizace tiše dělá svoje a vy se o problému dozvíte až od účetní.

Kdy to dává smysl

Nedělám si iluze, že tohle je řešení pro každého. Dává to smysl, když vám chodí dost faktur na to, aby přepisování bolelo, máte účetní systém s použitelným API a je ve firmě někdo, kdo pozná, že výstup nesedí.

Nedává to smysl, když máte pět faktur měsíčně, nebo když by ta samá práce jen přešla z účetní na někoho, kdo se bude o skript starat.

Cílem nebylo zrušit lidskou kontrolu. Cílem bylo zbavit ji přepisování, celý proces zefektivnit, zrychlit a snížit chybovost.