Jak stavím Invoicey: AI na okrajích, pravidla v jádru

Každý měsíc fakturuji jen několika klientům. Fakturace by tedy měla být jednoduchá.

Není.

Někdy fakturuji jako živnostník, jindy přes s.r.o. Každý subjekt má vlastní bankovní účet, číselnou řadu, nastavení DPH a vizuální identitu. Objem je malý; počet detailů, které musí být správně, ne.

Chtěl jsem fakturu jednou popsat—ideálně tam, kde už pracuji—a nechat nudné části proběhnout správně. Tak vzniklo Invoicey.

Nejzřejmější první verze byla ta špatná

Lákavým produktem byl chat napojený přímo na generátor PDF. Napsat větu, nechat model doplnit mezery a stáhnout něco, co vypadá jako faktura.

Faktura ale není próza. Má právní strany, daňové režimy, data, položky, součty, číslování, platební identifikátory a životní cyklus. Stejné hodnoty musí přežít cestu do PDF, platebního QR, účetního exportu, e-mailu i databáze.

Invoicey proto začalo opačnou architekturou: AI na okrajích, deterministická pravidla v jádru.

Webový formulář, JSON import, AI uvnitř aplikace, MCP i Slack se sbíhají v jednom validovaném InvoiceSchema. Od té chvíle už běžný kód počítá součty, uplatňuje DPH, přiděluje čísla, odvozuje stav a generuje soubory.

Začátek byl kvůli této hranici méně efektní. Všechno další je díky ní mnohem důvěryhodnější.

Pravidla vznikla dřív než dashboard

Repozitář začal 3. května 2026 produktovým zadáním, doménovým modelem, architekturou, roadmapou, slovníkem a šestnácti záznamy rozhodnutí.

Nebyla to dokumentace doplněná po zajímavé práci. Byla to první zajímavá práce.

Vymezil jsem tři skutečné scénáře: fakturaci z více subjektů, neobvyklé případy vystavení jménem někoho jiného nebo samofakturace a vytváření dokladů přes Slack či MCP. Faktury jsem zároveň navrhl jako snapshoty. Když klient příští rok změní adresu, loňský vystavený doklad se s ní nesmí tiše přepsat.

Stejná úvaha formovala stavový model. Faktura není „zaplacená“ proto, že někdo přepnul štítek, ale proto, že existuje údaj o platbě. Koncept, vystavená, po splatnosti, zaplacená a zrušená se odvozují z podkladových dat.

1. 3. května 2026

   Z pravidel vznikl funkční engine

   Schéma, součty, číslování, stav, české DPH, ARES, PDF, platební QR SPAYD, ISDOC 6.0.2 a první experiment se Slackem vznikly během jedné intenzivní etapy.

2. 10. srpna

   Z enginu vznikla aplikace

   Vrátil jsem se k perzistenci, dodavatelům, klientům, editoru faktur, seznamům, dashboardu, MCP nástrojům a trvalému Slack agentovi.

3. 11.–13. srpna

   Z aplikace vznikla platforma

   Přibylo OAuth, workspaces, pozvánky, e-mail, opakované koncepty, historický import, AI v aplikaci, více měn, doklady v češtině i angličtině, API klíče, bezpečnostní prvky a zpevnění produktu.

Jeden zdroj pravdy, několik vchodů

Jádro dnes rozumí fakturám, proformám, zálohovým fakturám a dobropisům. Zvládá české režimy DPH, DUZP, plnění v zahraničí, platební symboly, vlastní číslování každého dodavatele, více měn a české nebo anglické doklady. ARES dokáže doplnit firmu podle IČO nebo názvu.

Ze stejných validovaných dat vznikne čitelné PDF, SPAYD QR pro české bankovní aplikace a ISDOC 6.0.2 pro účetní software. Vystavené soubory jsou neměnné; starší PDF a ISDOC lze importovat bez přepsání jejich historie.

Kolem tohoto jádra má Invoicey několik vstupů:

• kompletní webové prostředí pro dodavatele, klienty, koncepty, vystavení, úhrady, dashboard a vyhledávání;
• strukturovaný JSON a tvorbu konceptu z promptu přímo v aplikaci;
• lokální i vzdálené MCP nástroje pro vytvoření, seznam, načtení, odeslání a označení faktury za zaplacenou;
• Slack agenta, který propojí Slack identitu se správným workspace a citlivé akce nechává za potvrzením.

Důležitý je detail, který se nestal: nevznikly čtyři mírně odlišné fakturační produkty. Všechny používají stejná pravidla.

1.24.0

Současná verze

Nejnovější vydání k 13. srpnu 2026.

178

Commitů v repozitáři

Soustředěných do pěti aktivních vývojových dní od května.

1

Smlouva faktury

Každé rozhraní se sbíhá v jednom validovaném schématu.

Produkt se po prvním vydání článku rychle změnil

Když jsem tento příběh poprvé zveřejnil 11. srpna, přihlášení, e-mail, opakované faktury a databázové operace přes MCP byly ještě budoucí plány. O dva dny později byl tento odstavec zastaralý.

Invoicey dnes podporuje přihlášení přes Google a GitHub, více workspaces, členy a pozvánky, propojené účty, správu relací, důvěryhodná zařízení, auditní historii a osobní API klíče. Každý workspace může mít několik dodavatelských subjektů a přitom v něm sdílet klienty.

Odesílání e-mailem je implementované včetně příloh PDF a ISDOC, událostí doručení, upozornění po splatnosti a potlačení adres po odražení nebo stížnosti. Opakované plány záměrně vytvářejí koncepty, ne automaticky vystavené faktury: automatizace připraví práci, ale poslední právní rozhodnutí zůstává člověku.

Stejný princip platí ve Slacku. Identita musí být výslovně propojená, stále patřit do workspace a použít jeho zvoleného dodavatele. Chybějící kontext skončí chybou místo pohodlného dosazení ukázkových dat.

To je nejpříjemnější druh pokroku: nejen více funkcí, ale jasnější hranice toho, co produkt smí udělat.

Kde je Invoicey skutečně dnes

Invoicey je nasazené a použitelné, stále ale jde o privátní betu—ne hotové veřejné nebo placené SaaS.

Produkt už pokrývá reálnou fakturaci. Nejbližší práce je méně efektní a důležitější: aplikovat a ověřit nejnovější databázové migrace ve správném pořadí, zopakovat přihlášené end-to-end testy, dokončit skutečné smoke testy e-mailu, importu a Slacku, vynutit CI a bezpečnostní politiku prohlížeče a doplnit právní a obchodní údaje nutné pro veřejné spuštění.

Teprve potom se chci vrátit k větším funkcím. Později mohou přijít dvojí jazykové popisky v jednom PDF, vlastní šablony, párování bankovních výpisů nebo dokupování AI tokenů. Daňové výkaznictví možná do Invoicey nebude patřit nikdy. Raději jej udržím výborné ve vystavování a správě faktur, než aby se z něj stal průměrný účetní systém.

Původní problém zůstává testem celého produktu: popsat fakturu jednou, ověřit ji a zajistit, aby všechny výstupy souhlasily.