Integrované účetnictví: Vývoj vs. nákup pro tržiště

Seznam požadavků, nákladový model s jasnými předpoklady a podmínky, za nichž je každá z možností správnou volbou.

Každé internetové tržiště dříve či později vytvoří vlastní hlavní knihu. Otázkou zůstává pouze to, zda vznikne záměrně jako systém s řádnými kontrolami, nebo náhodně v podobě sloupců balance, do nichž zapisují tři různé služby a kterým vlastně nikdo tak docela nevěří.

Tento článek se zabývá tím, jak toto rozhodnutí učinit vědomě. Dozvíte se v něm, co takový vývoj obnáší, jak realističtě spočítat náklady bez zbytečných iluzí a za jakých konkrétních podmínek je vývoj vlastními silami správnou volbou - protože občas tomu tak opravdu je.

Co zde rozumíme „integrovaným účetnictvím“

Integrované účetnictví (embedded accounting) znamená, že účetní záznamy žijí přímo uvnitř vašeho produktu, namísto toho, aby se nacházely v samostatné aplikaci, kterou někdo otevírá zvlášť. Váš software zaznamenává operace v okamžiku, kdy k nim dochází, uživatelé vidí přesně to, co jim vaše rozhraní zobrazuje, a na konci měsíce nikdo nemusí exportovat tabulky pro účetní.

Pro tržiště to obnáší minimálně: přijaté platby od kupujících, částky dlužené prodejcům, získané provize, poplatky za zpracování plateb, DPH z vašich poplatků i z podkladového plnění, vrácení peněz (refundace), zpětné zúčtování plateb (chargebacks), rezervy, výplaty peněz prodejcům a vzájemné párování (reconciliation) všech těchto položek s bankou či platební bránou.

Co vlastně stavíte, když se pustíte do vlastního vývoje

Samotná hlavní kniha (ledger) představuje jen menší část úkolu. Týmy při odhadech pravidelně obsáhnou první položku a zbytek objeví až následně.

Komponenta	Co to obnáší
Deník a účty	Vyrovnané položky, účtová osnova, typy účtů, počáteční stavy
Neměnnost (immutability)	Úložiště pouze pro připojování záznamů (append-only), workflow pro storno a opravy, žádné přímé úpravy existujících záznamů
Správa účetních období	Uzávěrka, uzamčení období, odmítnutí pozdních zaúčtování, řízené znovuotevření se záznamem v auditu
Idempotence	Klíče, ukládání předchozích odpovědí, detekce kolizí při změněných datech
Práce s penězi	Přesná aritmetika s desetinnými místy nebo haléři (minor units), kódy měn, směnné kurzy a jejich zdroj, zaokrouhlovací účty
DPH engine	Sazby pro jednotlivé země s platností v čase, místo plnění, přenesení daňové povinnosti (reverse charge), pravidla pro osobu povinnou k dani, osvobození
Kontroly registrace k DPH	Ověření vůči oficiálnímu registru, cachování, časová razítka, identifikátory požadavků, manuální fronta pro selhání
Dokumenty	Faktury, dobropisy, nepřerušená číselná řada dle řad a roku, vykreslování do PDF, doručení
Elektronická fakturace	Standardizované formáty jako EN 16931 UBL a národní formáty pro jednotlivé země, kde jsou povinné
Načítání bankovních výpisů	Import výpisů nebo propojení s bankou na základě souhlasu, deduplikace již importovaných transakcí
Párování	Pravidla pro párování, bodování, částečné shody, výjimky, které musí člověk vyřešit
Výplaty (payouts)	Generování platebních souborů, dávkové zpracování výplat, párování výplat zpět k podkladovým položkám
Reporting	Předvaha, rozvaha, výkaz zisku a ztráty, peněžní tok (cash flow), přehledy DPH, stárnutí pohledávek
Daňové evidence a přiznání	Cokoliv, co vaše země vyžadují, ve formátu, který úřad akceptuje
Audit	Kdo akci provedl, co udělal, nad jakou entitou a jaká byla samotná změna - vše dohledatelné pro každou mutaci
Uchovávání dat a export	Desetiletá archivace pro OSS záznamy, kompletní export dat, obhajitelný archiv

Přibližně dvě z těchto sedmnácti položek tvoří to, co si většina týmů představuje pod pojmem „postavíme hlavní knihu“.

Jak poctivě spočítat náklady

Jakákoliv čísla zde závisí na vašem týmu, berte proto následující postup spíše jako metodu než jako konkrétní cenovou nabídku. Vezměte výše uvedené komponenty, odhadněte u každé z nich časovou náročnost v inženýr-týdnech na základě rychlosti vašeho týmu a aplikujte tři korekce, které odhady obvykle opomíjejí.

První korekce: komponenty pro zajištění souladu s předpisy (compliance) nejsou jednorázovou záležitostí. Sazby se mění, limity se mění, formáty se mění a balíček EU ohledně DPH v digitálním věku (ViDA) přináší časově vymezené povinnosti - změny OSS a IOSS od 1. ledna 2027, rozšířená pravidla pro platformy od 1. července 2028 a přeshraniční digitální hlášení od 1. července 2030. Vlastní vývoj znamená, že každou tuto migraci musíte uřídit sami.

Druhá korekce: práce na zajištění správnosti trvá déle než tvorba samotných funkcí. První verze zvládne ideální scénář (happy path). Dlouhý chvost problémů zahrnuje refundace po provedení výplaty, částečné refundace, zpětná zúčtování dorazivší o týdny později, zaokrouhlování měn, duplicitní webhooky a vypořádávací soubory, které se neshodují s vašimi záznamy. Právě zde se vytrácí časový harmonogram.

Třetí korekce: účetní je klíčovým účastníkem projektu, nikoliv pouhým schvalovatelem. Účetnictví, které odmítne finanční profesionál podepsat, není hotové, a tato zpětná vazba přichází v průběhu vývoje obvykle příliš pozdě.

Užitečná kontrola reálnosti: zkuste nacenit nejmenší věrohodnou verzi - hlavní knihu, opravné položky, zamykání období, idempotenci, práci s penězi, DPH pro jednu zemi, faktury, bankovní import, párování a základní sadu sestav - a porovnejte ji s ročními náklady na placenou službu. Ceny zveřejněných tarifů služby Nordlet začínají na 10 EUR měsíčně včetně 3 000 požadavků a končí na 300 EUR měsíčně pro 200 000 požadavků. Pokud vývoj stojí zlomek roční práce jediného inženýra, je to pádný argument pro vlastní vývoj. Pokud stojí několik inženýro-roků plus trvalou údržbu, srovnání nevychází příznivě - a s každým dalším rokem, kdy se pravidla mění, je to horší.

Kdy má vlastní vývoj skutečně smysl

Existují tři situace, kdy je to správná volba, a všechny jsou reálné.

Hlavní kniha je vaším produktem. Pokud stavíte platební platformu, bankovní produkt nebo peněženku, kde je chování zůstatků za souběžného provozu (concurrency) vaším hlavním odlišením na trhu, hlavní kniha je jádrem vašeho byznysu a měla by být vaše. Zvažte však raději existující infrastrukturu hlavních knih namísto vývoje od záruky a oddělte zákonné účetnictví.

Váš model nezapadá do žádného účetního systému. Některá tržiště využívají skutečně netradiční struktury vypořádání - vícestranné rozdělení plateb s podmíněným uvolněním peněz, úschovu (escrow) s fázovanými milníky nebo složitá pravidla pro rezervy. Pokud žádný produkt takový model nepodporuje a náhradní řešení jsou horší než vlastní vývoj, pak stavějte sami.

Váš objem transakcí činí cenotvorbu za použití služeb nevýhodnou. Při dostatečně extrémním počtu transakcí přestává být platba za každý požadavek atraktivní. Než toto předpoklad učiníte, ověřte si to na reálných číslech, protože „extrémní“ v tomto kontextu znamená hodnoty vyšší, než jich dosahuje většina platforem.

Kdy je nákup správnou volbou

Nákup vyhrává v situacích, kdy je účetnictví nutností, nikoliv však konkurenční výhodou, což je naprostá většina případů. Nikdo si vaše tržiště nevybere proto, že máte elegantní účetní zápisy. Zákazníci si všimnou pouze toho, když jsou účty špatně.

Nákup je rovněž správnou volbou, pokud vaše povinnosti přesahují hranice jedné země. Pravidla DPH pro jednotlivé země, uchovávání důkazů a povinnosti v oblasti elektronické fakturace představují trvalý proud úkolů spojených s údržbou a dodavatel tuto práci rozvrhne (amortizuje) mezi všechny své zákazníky. Nordlet dodává DPH v EU pro jednotlivé země s ověřením v systému VIES, výpočtem přiznání OSS a IOSS, registry i.SAF a formátem EN 16931 UBL pro síť Peppol jako součást produktu, nikoliv jako projekt, který musíte sami plánovat.

Střední cesta, ke které většina týmů nakonec dospěje

Praktická odpovědnost obvykle neleží na ani jedné z krajních možností. Zní takto: kupte hlavní knihu, naprogramujte si pracovní postupy (workflow).

Účetní backend spravuje zápisy, daňový režim, dokumenty, uzávěrky období a auditní stopu. Váš produkt spravuje vše, co vidí uživatelé, a veškerá obchodní pravidla specifická pro vaše tržiště - kdy se uvolňují peníze, jaká je politika rezerv, jak se řeší spory, co zobrazuje panel prodejce. Účetní API voláte v okamžicích, kdy dochází k závazným finančním operacím, a ponecháváte si ty části, které jsou skutečně vaše.

Tato hranice také snáší změny lépe než alternativní přístupy. Přidání nové země znamená novou konfiguraci namísto celého projektu. Nová pravidla pro výplaty jsou vaším kódem, nikoliv požadavkem na dodavatele.

Co je nutné rozhodnout dříve, než se do čehokoliv pustíte

Je vaše hlavní kniha odlišujícím prvkem, nebo zákonnou povinností? Buďte upřímní, ve většině případů jde o povinnost.
Kolik zemí obsluhujete a co každá z nich vyžaduje? Pouze sazby, nebo přiznání, registry či samotné podávání hlášení?
Jaký je váš plán pro opravy chyb? Refundace po výplatě a opožděná zpětná zúčtování jsou situace, které odhalí slabý návrh.
Kdo účetnictví podepisuje? Zapojte tuto osobu ještě předtím, než bude návrh hotový, nikoliv až po něm.
Jaký je plán pro desetiletou archivaci? Záznamy v režimu OSS je nutné uchovávat deset let od konce roku transakce a archiv je systémem, nikoliv pouhou zálohou.
Jak bude vypadat migrace za tři roky? A to v obou směrech. Připravte si testovací export hned první den a dbejte na to, aby fungoval.

FAQ

Jak dlouho trvá vývoj hlavní knihy pro tržiště?

První verze, která zaznamenává vyrovnané položky, může fungovat během několika týdnů. Verze, která zvládá refundace po výplatě, opožděná zpětná zúčtování, zaokrouhlování ve více měnách, duplicitní webhooky poskytovatelů, uzávěrky období a audit akceptovatelný pro účetního, zabere výrazně více času a údržba nekončí nikdy. Odhadujte raději tu druhou variantu, protože to znamená reálný provoz.

Můžeme začít se sloupcem `balance` a migrovat později?

Můžete a mnoho týmů to tak dělá, ale počítejte s tím, že migrace bude náročnější než původní vývoj. Rekonstrukce historie z měnitelného zůstatku je možná pouze tehdy, pokud jste uchovávali každou událost, která jej změnila - což vlastně znamená, že jste již hlavní knihu měli.

Nahradí integrované účetní API náš finanční tým?

Ne. Odstraňuje ruční pořizování záznamů a párování. Někdo však stále musí uzavírat měsíc, prověřovat výjimky, činit odborná rozhodnutí a podávat přiznání.

Jak je to s GDPR, pokud je hlavní kniha neměnná?

Uchovávejte peněžní údaje a pseudonymizované odkazy v neměnných záznamech, zatímco osobní údaje uložte v samostatném systému s vlastními procesy pro uchovávání a mazání. Princip neměnnosti se vztahuje na finanční událost, nikoliv na každý atribut, který je k ní připojen.

Je open-source účetní software schůdnou střední cestou?

Jde o reálnou možnost, která však náklady spíše mění, než aby je odstraňovala: přebíráte odpovědnost za hosting, aktualizace, lokalizaci pro jednotlivé země a sledování legislativních změn. Tyto náklady si spočítejte předtím, než úsporu na licencích začnete považovat za vyřešenou věc.