Double-Entry Ledger API pro účetnictví tržišť

Většina tržišť zjistí, že má problém s účetnictvím, vždy stejně: do firmy nastoupí nová posila do financí, otevře si tabulku s výplatami a zeptá se, kdo vlastně eviduje závazek vůči prodejcům v době mezi platbou kupujícího a odchodem peněz z účtu platformy. Vývojový tým ukáže na tabulku transactions. Finanční specialista namítne, že tabulka událostí není účetní kniha. Právě tuto propast mezi daty o událostech a skutečným účetnictvím má za úkol zacelit API podvojného účetnictví.

Jedná se o technickou otázku se silným regulačním dopadem. Tržiště drží peníze jiných lidí, vypočítávají DPH napříč jurisdikcemi a jménem prodejců vystavují faktury. Dělat to pomocí podomácku vytvořené tabulky transakcí funguje jen do chvíle, než auditor, daňový úřad nebo vážný zájemce o koupi požádá o důkazy.

Co API podvojného účetnictví ve skutečnosti je

API podvojného účetnictví je programovatelný účetní engine zpřístupněný přes HTTP. Každá finanční událost, kterou vaše platforma zaznamená, se zapíše jako vyrovnaný účetní zápis: minimálně jeden má dáti a jeden dal, které se celkově rovnají a jsou zaúčtovány na pojmenované účty v účtové osnově. API vynucuje tuto rovnováhu již v okamžiku zápisu a ukládá záznamy tak, aby je nebylo možné později potichu upravit.

Část „podvojného“ vychází ze čtyř set let starého účetního pravidla, že každá transakce ovlivňuje minimálně dva účty. Část „API“ znamená, že volajícím je váš produkt, nikoli lidský účetní. Část „neměnného“ (immutable) znamená, že opravy se provádějí pomocí stornujících zápisů, nikoli přepisováním historie. Tyto tři vlastnosti společně zajišťují, že výsledné účetnictví je připravené na audit a není jen ledabyle uspořádané.

Užitečná pracovní definice:

API podvojného účetnictví přijímá finanční události z vaší aplikace, každou z nich převádí na vyrovnaný účetní zápis proti definované účtové osnově, tyto záznamy ukládá neměnným způsobem a prostřednictvím předvídatelných koncových bodů zpřístupňuje výslednou hlavní knihu, obratovou předvahu a finanční výkazy.

Nordlet je postaven přesně na této myšlence: skutečné účetnictví formou API, přičemž hlavní kniha, logika DPH, fakturace a odsouhlasování jsou dostupné ze stejné sady koncových bodů, se kterými už vaše platforma komunikuje.

Proč to tržiště specificky potřebují

SaaS pro jednoho obchodníka si často vystačí s každodenní synchronizací s obecným účetním nástrojem. Tržiště však nikoliv, a to ze tří důvodů.

Za prvé, stojí uprostřed toku peněz. Kupující zaplatí platformě, platforma drží finanční prostředky a poté vyplácí prodejcům částku sníženou o poplatky. Každý z těchto pohybů představuje samostatnou účetní událost ovlivňující různé účty: hotovost, závazky vůči prodejcům, výnosy platformy, závazky na DPH, rezervy na vrácení plateb. Tabulka payments se sloupcem status toto nezachytí.

Za druhé, operují napříč daňovými jurisdikcemi. Tržiště v EU s prodejci v Litvě, Německu a Polsku a s kupujícími napříč unií musí u každé transakce aplikovat správný režim DPH, ověřovat DIČ prodejců prostřednictvím VIES a vytvářet výkazy, které uspokojí úřady v každé příslušné zemi. Zvládnout to v kódové základně aplikace a následně to odsouhlasovat s odděleným účetním systémem je bod, kde většina tržišť potichu ztroskotá.

Za třetí, objem dat odporuje manuálnímu účetnictví. Platforma realizující deset tisíc objednávek měsíčně generuje desítky tisíc účetních zápisů. To musí být plně zautomatizováno, jinak se finanční oddělení stane brzdou růstu.

Jak API funguje krok za krokem

Mechanika je méně exotická, než se zdá. Typický tok pro objednávku na tržišti vypadá následovně:

1. Vaše platforma odešle finanční událost. Kupující dokončí nákup. Váš backend zavolá API hlavní knihy s údaji, jako jsou: ID objednávky, kupující, prodejce, hrubá částka, sazba DPH, provize platformy, měna a idempotentní klíč.

2. Hlavní kniha sestaví účetní zápis. API přeloží tuto událost na položky má dáti a dal. U přímočarého prodeje na tržišti to může znamenat zaúčtování na vrub (má dáti) účtu peněz na cestě, ve prospěch (dal) účtu závazků vůči prodejci za čistou částku, ve prospěch účtu výnosů platformy za provizi a ve prospěch účtu závazků na DPH za daňovou část. Vše je vyrovnané. Vše je zaúčtováno atomicky.

3. Záznam se zapíše neměnným způsobem. Po zaúčtování získá záznam identifikátor a časové razítko a nelze jej upravit. Pokud je něco špatně, zaúčtujete stornující zápis a opravený zápis. Právě auditní stopa je hlavním smyslem.

4. Následné výkazy se aktualizují v reálném čase. Obratová předvaha, zůstatky závazků vůči prodejcům, přehledy DPH a výsledovka odrážejí nový záznam okamžitě. Neexistuje žádná noční úloha, žádný export ani okno pro párování, kdy se čísla „usazují“.

5. Webhooky informují váš systém. Události jako sale_invoice.paid nebo bank_transaction.matched se odesílají na vaše koncové body, takže váš produkt může reagovat bez nutnosti neustálého dotazování (polling). V kombinaci s idempotentními klíči to znamená, že opakované pokusy jsou bezpečné a při výpadku sítě nevznikají duplicity.

Důležitý designový bod: hlavní kniha je zdrojem pravdy pro to, co se stalo po finanční stránce. Databáze vaší aplikace je zdrojem pravdy pro stav produktu. Oba systémy se vzájemně shodují, protože hlavní kniha se zapisuje na základě aplikačních událostí, nikoli naopak.

Účtová osnova je místem, kde se rodí návrh systému

Většina myšlenkového úsilí při nastavování hlavní knihy pro tržiště spočívá v účtové osnově. Jde o seznam pojmenovaných účtů, kam směřují částky má dáti a dal: hotovostní účty pro jednotlivé banky, účty závazků vůči prodejcům (často jeden pro každého prodejce nebo jeden souhrnný s analytikami), výnosy platformy podle kategorií, závazky na DPH podle zemí, rezervy na vrácení peněz, rezervy na chargebacky a tak dále.

Několik vzorů, které se u tržišť opakují:

• Peníze prodejců jsou závazkem, nikoliv výnosem. Peníze, které držíte jménem prodejců, představují závazek. Považovat je za výnos a výplatu později účtovat do nákladů je klasická chyba, která se ukáže při hloubkové kontrole (due diligence).
• DPH představuje samostatný závazek pro každou zemi. Pokud působíte v jurisdikcích EU, potřebujete pro každou zemi samostatné účty závazků na DPH, aby se výkazy dalo snadno mapovat.
• Poplatky je nutné modelovat v okamžiku jejich získání, nikoliv při jejich vyplacení. Akruální účetnictví zde není volitelné.
• Vracení plateb, chargebacky a spory vyžadují vlastní účty, aby výsledovka odrážela realitu namísto změti kladných a záporných prodejů.

Dobré API hlavní knihy vám umožňuje definovat tuto strukturu jednou a poté do ní s jistotou účtovat, namísto abyste znovu vynalézali účetní logiku uvnitř kódu pokladny.

Neměnnost, uzamykání období a důvody, proč na tom auditorům záleží

Neměnnost (immutability) zní jako detail z oblasti databází. Ve skutečnosti je to rozdíl mezi účetnictvím, pod které se auditor podepíše, a účetnictvím, pod které se nepodepíše.

Pokud může tržiště potichu upravovat zápisy z minulého čtvrtletí, jsou čísla z minulého čtvrtletí v účetním slova smyslu nepoznatelná. Neměnná hlavní kniha prosazuje pravidlo, že historie je historií. Opravy jsou viditelné jako opravy. Uzamykání období toto rozšiřuje: jakmile je měsíc uzavřen, nelze do tohoto období umístit žádné nové zápisy ani úpravy bez explicitní akce opětovného otevření, která se sama zaznamená do protokolu.

Pro platformy, které budou v budoucnu získávat financování, prodávat se nebo čelit daňové kontrole, to není „pěkná funkce navíc“. Je to prvek, díky kterému je účetnictví obhajitelné. Hlavní kniha od Nordletu je na tom postavena standardně, přičemž neměnná struktura podvojného účetnictví a uzamykání období jsou integrovány přímo v základu.

DPH v EU: oblast, která pohlcuje čas vývojářů

DPH je oblast, kde většina projektů zaměřených na účetnictví tržišť překračuje rozpočet. Pravidla nespočívají jen v „aplikování procenta“. Záleží na tom, kde se nachází kupující, kde prodejce, co se prodává, zda je prodejce plátcem DPH, zda je tržiště považováno za dodavatele podle pravidel pro elektronické obchodování z roku 2021 a který režim podávání přiznání se v daném místě uplatňuje.

Důkladné API hlavní knihy pro EU zvládá minimálně:

• Ověření VIES pro DIČ prodejců i kupujících, ideálně s výsledky uloženými v mezipaměti a připojenými k transakci
• Logiku sazeb DPH pro jednotlivé země, včetně snížených sazeb a výjimek
• Generování i.SAF registru pro litovská přiznání a ekvivalentní strukturované výstupy v jiných členských státech, kde jsou vyžadovány
• Elektronickou fakturaci Peppol BIS 3.0 pro jurisdikce přecházející na povinnou e-fakturaci
• Zpracování v režimu OSS/IOSS pro přeshraniční B2C prodeje

Dělat to v aplikačním kódu pro každou zemi zvlášť představuje práci pro celý vývojářský tým, která nikdy opravdu nekončí, protože se neustále mění pravidla. Přesun této logiky do vrstvy hlavní knihy je pragmatickým krokem.

Odsouhlasování šetří čas

Jakmile je hlavní kniha zdrojem pravdy, přestává být párování bankovních výpisů měsíčním utrpením. Přicházejí bankovní výpisy, hlavní kniha už ví, co by v nich mělo být, a párování probíhá převážně automaticky.

Realistická podoba nevypadá jako „nulová manuální práce“. Vypadá jako „výjimky se ukáží samy“. Jedno-klikové párování pro devadesát procent transakcí, které se přesně shodují, plus fronta deseti procent vyžadujících lidské rozhodnutí, je zhruba to, co dobře navržené API pro odsouhlasování přináší. Inteligentní párování plateb zvládá částečné platby, preplatky a platby pokrývající více faktur, aniž by člověk musel pro každý případ psát pravidla.

SEPA export (formát pain.001) pro výplaty dodavatelům a prodejcům uzavírá smyčku na výstupní straně. Schválíte výplaty ve svém produktu, hlavní kniha vygeneruje SEPA soubor, vaše banka jej zpracuje a výsledný pohyb se automaticky spáruje.

Vlastní řešení vs. nákup vs. integrace

Týmy provozující tržiště obvykle zvažují tři cesty. Zde je jejich srovnání podle klíčových kritérií.

Přístup	Doba do spuštění	Připravenost na audit	Zpracování DPH v EU	Začlenění do produktu
Vlastní vývoj hlavní knihy	12 až 24+ měsíců	Záleží čistě na vašem týmu	Vyvíjíte sami, pro každou zemi	Ano
Synchronizace do Xero/QuickBooks	Týdny	Dobrá pro účetní část, slabá pro specifické toky tržiště	Částečné, vyžaduje doplňky	Ne, probíhá v jiném nástroji
Integrace API hlavní knihy (např. Nordlet)	Týdny	Integrována přes neměnnou knihu a uzamykání období	Integrována pro EU, včetně VIES a i.SAF	Ano, přes API a SDK

Vlastní vývoj dává smysl tehdy, když je účetnictví vaším produktem. Pro všechny ostatní vychází matematika málokdy příznivě. Synchronizace s tradičním účetním nástrojem funguje u subjektů s jedinou firmou, ale při tocích na tržišti naráží na limity: rozdělené platby, sub-ledgery prodejců, DPH podle jednotlivých zemí a scénáře, kdy je platforma považována za dodavatele, se špatně mapují do nástrojů navržených pro účetnictví jedné společnosti.

Integrace API hlavní knihy je směr, ke kterému se moderní platformy ubírají. Účetnictví žije uvnitř uživatelského prostředí vašeho produktu, prodejci vidí své vlastní finance ve vašem rozhraní a složitou oblast compliance řeší infrastrukturní vrstva.

Co sledovat při výběru API hlavní knihy

Krátký kontrolní seznam, který se vyplatí mít po ruce během hovorů s dodavateli:

• Neměnné úložiště podvojného účetnictví s opravami formou stornujících zápisů namísto upravitelných řádků
• Uzamykání období se zaznamenanými akcemi opětovného otevření
• Idempotentní klíče u každého koncového bodu pro zápis
• Webhooky pro události, na které váš produkt potřebuje reagovat, nikoliv pouze polling API
• Typová SDK v jazycích, které váš tým skutečně používá
• Logika DPH pro jednotlivé země, včetně VIES, i.SAF nebo ekvivalentů, a režimů OSS/IOSS
• Podpora pro více společností, pokud provozujete více entit nebo to plánujete
• Řízení přístupu na základě rolí dostatečně granulární pro oddělení vývojářů, účetních a uživatelů s právem čtení
• Exporty výkazů ve formátech XLSX, PDF a JSON s notifikací přes webhook, jakmile jsou velké sestavy připraveny
• Sandbox, který věrně zohledňuje chování produkčního prostředí, nikoliv ořezané demo

Pokud dodavatel nedokáže v technickém hovoru předvést první tři body, na zbytku už nezáleží.

Co bych udělal jako první

Pokud tržiště začíná s touto prací od nuly, postup, který ušetří nejvíce starostí:

1. Než napíšete jakýkoliv kód, namalujte si na tabuli skutečné toky peněz. Kdo komu dluží, v jakém okamžiku, v jaké měně a s jakým režimem DPH.
2. Z tohoto schématu navrhněte účtovou osnovu. Závazky prodejců, výnosy platformy, závazky na DPH podle zemí, rezervy. Nechte ji před nasazením do produkce zkontrolovat účetním.
3. Vyberte vrstvu hlavní knihy. Zvolte vlastní vývoj, synchronizaci, nebo integraci. Buďte upřímní v tom, co váš tým skutečně dokáže dodat a udržovat.
4. Implementujte jeden tok od začátku do konce: objednávka až po fakturu, výplatu a párování. Dokažte, že se zůstatky rovnají. Teprve potom škálujte.
5. Zapněte uzamykání období hned po čistém uzavření prvního měsíce. Tato disciplína se postupně zúročí.

Týmy, které to zvládnou správně, přistupují k hlavní knize jako ke své klíčové infrastruktuře, nikoliv jako k dodatečně doplněnému reportu. Právě to je tou hlavní změnou, která proměňuje debatu s auditorem, investorem nebo daňovým úřadem v krátkou a bezproblémovou záležitost.

FAQ

Je API podvojného účetnictví totéž co účetní integrace?

Ne. Integrace synchronizuje data z vašeho produktu do externího účetního nástroje, obvykle se zpožděním. API hlavní knihy představuje samotný účetní systém, do kterého se zapisuje přímo a v reálném čase. Tento rozdíl je klíčový, protože integrace na okrajích ztrácejí přesnost: částečné platby, více měn, rozdělení plateb na tržišti. API hlavní knihy tyto operace zaznamenává přirozeně.

Nemůžeme prostě používat reporty od Stripe nebo Adyen?

Reporty platebních brán ukazují, co prošlo přes danou bránu. Nejsou to knihy podvojného účetnictví. Nevědí nic o vašich závazcích vůči prodejcům, které ještě nebyly vyplaceny, o vašich závazcích na DPH napříč zeměmi ani o nákladech nesouvisejících s platební bránou. Představují pouze jeden vstup do hlavní knihy, nikoliv její náhradu.

Jak moc je neměnné úložiště v praxi neměnné?

Záznamy nelze upravovat. Opravy jsou tvořeny novými záznamy, které odkazují na ty původní. Jde o architektonické rozhodnutí, nikoliv o technologické omezení. Každá schopná hlavní kniha to bude vynucovat. Důvod, proč na tom záviset, spočívá v tom, že přístup „upravili jsme to tak, aby to sedělo s bankou“, je přesně tím vzorem, který dělá účetnictví nedůvěryhodným.

A co tržiště mimo EU?

Mechanika podvojného účetnictví je univerzální. Daňová logika nikoliv. API hlavní knihy vyladěné pro DPH v EU zvládá operace zaměřené na EU skvěle a dokáže podpořit i transakce mimo EU, ale pokud je vaším hlavním trhem americká daň z obratu (sales tax) nebo jihoamerické režimy e-fakturace, ověřte si předem konkrétní pokrytí legislativních požadavků.

Jak dlouho vlastně trvá implementace?

V případě tržiště s přehledným modelem událostí zabere integrace API hlavní knihy do stavu, kdy funguje jeden kompletní tok od začátku do konce, obvykle několik týdnů vývoje. Úplná migrace ze staršího nastavení včetně historických dat trvá déle. Proměnnou je téměř vždy stav stávajících dat, nikoliv samotné API.