Co je to účetní API? Praktický průvodce bez žargonu pro tvůrce platforem

Srozumitelná definice účetního API, rozdíl oproti daňovému nebo platebnímu API a přehled toho, co si ověřit před zahájením integrace.

Účetní API je rozhraní, které umožňuje jednomu programu spravovat účetnictví jiného programu. Vaše software odešle finanční událost přes HTTP. API tuto událost promění v souladu s účtovou osnovou na vyrovnané položky podvojného účetnictví, uloží je tak, aby je nebylo možné potichu změnit, aplikuje příslušný daňový režim a přes stejné rozhraní vám vrátí reporty, dokumenty a exporty.

Tato definice vystihuje podstatu. Všechno ostatní v tomto článku z ní pouze vychází.

Verze v jedné větě

Účetní API přijímá finanční události z vaší aplikace, každou z nich převádí na vyrovnaný účetní zápis, neměnně ji ukládá včetně daňového režimu a podpůrných dokladů a výslednou hlavní knihu, dokumenty a reporty zpřístupňuje jako programová koncová bodová rozhraní (endpoints).

Pokud se nějaký produkt označuje jako účetní API, ale nevytváří účetní zápisy, jedná se o něco jiného s hezkým názvem. To nutně nemusí být špatně, jen to znamená, že to nezvládne úkol, který po něm budete chtít.

Čím účetní API není

Čtyři příbuzné kategorie produktů se s účetními API často zaměňují, obvykle v pokročilé fázi projektu.

Kategorie	Co to dělá	Co to nedělá
API pro výpočet daní	Vrací správnou sazbu nebo výši daně pro danou transakci	Nevede vaše účetnictví ani neuchovává důkazy o rozhodnutí po dobu archivační lhůty
Platební API	Přesouvá peníze mezi stranami a reportuje o těchto pohybech	Nezaznamenává provizi, dlužnou DPH ani závazek vůči prodejci mezi okamžikem platby a výplaty
Unified API neboli agregátor	Čte a zapisuje data do stávajícího účetního softwaru vašich zákazníků	Nepředstavuje primární zdroj dat (system of record); vaše účetnictví žije v nástroji, který už každý zákazník používá
Reportovací nebo BI API	Čte čísla z existující hlavní knihy a vizualizuje je	Nevytváří zápisy, ze kterých jsou tato čísla odvozena

Každé z těchto řešení má své opodstatnění. Platforma, která musí sloužit jako primární zdroj dat, však potřebuje účetní API jako základ pod sebou, nikoli místo sebe.

Pět věcí, které účetní API musí zvládnout

1. Zaznamenávat vyrovnané zápisy. Každá událost se promění v má dáti a dal, jejichž součet dává stejnou částku. Když kupující zaplatí na tržišti 100 EUR a tržiště si strhne provizi 15 EUR, zápis zaúčtuje 100 EUR na průběžný účet (má dáti), 85 EUR jako závazek vůči prodejci (dal) a 15 EUR jako výnos z provizí (dal). Nejedná se o zbytečnou formalitu, nýbrž o strukturální kontrolu, která zachytí celé kategorie chyb při integraci ještě předtím, než se promítnou do reportů.

2. Uchovávat historii. Zaúčtovaný záznam se nemění. Chyba se opravuje stornem a následným opraveným zápisem, přičemž oba jsou propojeny s původním dokladem. Uzavřená období jsou uzamčena, takže do nich nelze datovat nic nového.

3. Vyřešit daňovou problematiku. V kontextu obchodu v rámci EU to znamená určení místa plnění, přenesení daňové povinnosti (reverse charge), ověření DIČ v oficiálním registru a uložení důkazů, které toto rozhodnutí opravňovaly, přímo u transakce namísto jejich smazání po výpočtu.

4. Párovat s externími penězi. Účetnictví, které se nikdy nesetká s bankovním výpisem, je pouhým odhadem. API musí umět přijímat výpisy nebo vypořádání od poskytovatelů plateb a párovat je se zaúčtovanými položkami.

5. Exportovat data. Reporty, dokumenty a auditní soubory ve formátech, které akceptuje lidský účetní i finanční úřad.

Produkt, který zvládá první tři body, ale zbývající dva nikoliv, bude stále vyžadovat, aby někdo každý měsíc pracoval v tabulkových procesorech.

Jak vypadá skutečné volání

Mechanika je jednodušší než samotné účetnictví. V API Nordletu je každá operace ve stylu RPC metodou POST s předvídatelnou strukturou:

POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>

Vytvoříte vydanou fakturu a následně ji vystavíte. Vystavení je okamžikem, kdy dochází k zaúčtování: dokument získá své číslo bez mezer, zaúčtuje se vyrovnaný účetní zápis a spolu s ním se zaznamenají i řádky DPH. Vaše platforma nikdy nemusí skládat má dáti a dal ručně.

Tři detaily v této ukázce jsou důležitější než název koncového bodu:

Omezení oprávnění klíče (scope). Klíč nese oprávnění jako sales:write, takže integrace má přístup pouze k tomu, co skutečně potřebuje.
Idempotentní klíč (Idempotency-Key). Pokud odešlete stejný požadavek se stejným obsahem, vrátí se vám uložená odpověď namísto vytvoření druhé faktury. Když pošlete stejný klíč s jiným obsahem, požadavek se odmítne s chybou idempotency_key_reuse, místo aby byl potichu přijat.
Peníze jako řetězce. Částky jsou desetinné řetězce, nikoliv čísla s plovoucí řádou (floats), protože plovoucí řádová čárka způsobuje ztrátu centů způsobem, který se projeví na konci roku.

Kam zapadá v architektuře

Vaše aplikace zůstává front-endem a zdrojem obchodních událostí. Účetní API se stává finančním systémem záznamu (system of record) v pozadí. Tok dat obvykle vypadá následovně:

Ve vašem produktu se něco stane: objednávka, vrácení peněz, výplata, obnova předplatného.
Váš backend zavolá účetní API s událostí a idempotentním klíčem.
API zaúčtuje položku, aplikuje DPH a vrátí identifikátory, které si uložíte k vlastním záznamům.
Webhook jako například sale_invoice.paid informuje váš systém o změně stavu, takže reagujete na události namísto neustálého dotazování (polling).
Bankovní transakce dorazí prostřednictvím bankovního feedu nebo importu výpisu a spárují se se zaúčtovanými dokumenty.
Na konci období se ze stejných dat vygenerují reporty a daňové evidence a uzavřené období se uzamkne.

Nic z toho nevyžaduje, aby člověk otevíral účetní program. V tom spočívá smysl této kategorie.

Srovnání s alternativami

Přístup	Náročnost na start	Pozice při auditu	Škálovatelnost s objemem transakcí
Tabulky a ruční zadávání	Nejnižší	Slabá; historii lze upravovat	Ne
Účetní aplikace plus exporty v CSV	Nízká	Záleží čistě na disciplíně	Špatná; soubory někdo musí importovat
Agregátor API do účetnictví každého zákazníka	Střední	Dědí vlastnosti nástroje konkrétního zákazníka	Ano, ale záznamy nevlastníte vy
Embedded účetní API	Střední	Silná, pokud je hlavní kniha neměnná a období se uzamykají	Ano
Vlastní vývoj hlavní knihy	Nejvyšší	Silná pouze tehdy, pokud si sami vyvinete i kontroly	Ano, ale udržujete ji navždy

Vlastní vývoj je pro některé týmy legitimní volbou. Podrobněji se jí věnujeme v našem průvodci pro tržiště zabývajícím se otázkou vývoje vlastní cesty oproti nákupu hotového řešení.

Co si ověřit před zahájením integrace

Je zůstatek odvozený, nebo uložený? Zjistěte, zda je zůstatek prodejce výsledkem dotazu nad účetními řádky, nebo sloupcem v databázi, který někdo aktualizuje. Pouze jedna z těchto možností obstojí při auditu.
Co se stane při opakování požadavku (retry)? Pošlete stejný požadavek dvakrát a spočítejte vzniklé položky.
Lze upravit zaúčtovaný zápis? Odpověď by měla znít ne, přičemž musí existovat zdokumentovaný postup opravy.
Uzamčené období skutečně odmítne zaúčtování? Vyzkoušejte si to v sandboxu. Nordlet vrací kód 409 pro zápisy datované do uzamčeného období.
Jak jsou reprezentovány peníze? Desetinné řetězce, nebo celočíselné minoritní jednotky haléřů či centů? Nikdy nepoužívejte plovoucí čárku.
Co obsahuje auditní záznam? Kdo akci provedl, co udělal, jaký subjekt ovlivnil a jaká byla samotná změna. Tyto údaje musí být dohledatelné dotazem, nikoliv schované v souborech protokolů (logů).
Jaké jsou limity počtu požadavků (rate limits)? Nordlet umožňuje 300 požadavků za minutu na jeden API klíč a zbývající limit hlásí v hlavičkách odpovědí. Ať už je to jakékoliv číslo, zjistěte si ho dříve, než navrhnete synchronizaci.
Jak se dostanete ke svým datům? Reporty, dokumenty a deníky ve formátech, které můžete předat účetnímu.

Každý z těchto bodů lze otestovat během jednoho odpoledne proti sandboxové společnosti. Seznamy funkcí od dodavatelů nejsou důkazem, tím je pouze reprodukovatelný test.

FAQ

Je účetní API to samé co účetní software?

Je to účetní software, u kterého se změnil typ rozhraní. Tradiční účetní software staví před hlavní knihu člověka, zatímco účetní API k ní staví váš kód. Základní povinnosti, struktura podvojného účetnictví a reporty zůstávají stejné.

Budu i nadále potřebovat účetního, když ho budu používat?

Ano. API automatizuje pořizování záznamů, výpočty a reportování. Nedělá však odborná rozhodnutí ohledně klasifikace, rezerv nebo toho, jak se má posuzovat konkrétní smlouva, a ve většině zemí za vás nepodepíše ani neodešle statutární účetní závěrku.

Mohu používat účetní API bez znalosti podvojného účetnictví?

Částečně. Kvalitní API za vás sestaví účetní zápisy z obchodního dokladu, jako je například faktura. Stále však musíte rozumět tomu, co jednotlivé účty znamenají, když čtete report nebo vysvětlujete zůstatek auditorovi.

Jaký je rozdíl mezi účetním API a API hlavní knihy (ledger API)?

API hlavní knihy zaznamenává vyrovnané pohyby mezi účty. Účetní API dělá totéž a navíc přidává statutární vrstvu: dokumenty s legálním číslováním, režim DPH, daňové evidence, dlouhodobý majetek, uzávěrku období a reporty, které daná jurisdikce vyžaduje. Každé účetní API obsahuje hlavní knihu, ale ne každá hlavní kniha je účetním systémem.

Jak dlouho trvá integrace?

U prvního funkčního oběhu dat – vytvořit zákazníka, vystavit fakturu, přijmout platbu a vidět účetní zápis – počítejte s dny, nikoli týdny, pokud máte k dispozici SDK s typovou kontrolou a sandbox. Produkční integrace pokrývající vrácení peněz, opravy, práci s více měnami, párování a uzávěrku období je již rozsáhlejší úkol a poctivý odhad závisí na tom, kolik z těchto scénářů váš produkt reálně generuje.