Nejlepší API pro automatizaci účetnictví pro unijní tržiště (2026)

Nejrychlejší způsob, jak zjistit, zda bylo účetní API vytvořeno s ohledem na tržiště, je položit otázku, co se stane, když litevský kupující zaplatí německému prodejci za produkt odeslaný z polského skladu a platforma si strhne 12% podíl plus poplatek za zpracování platby. Pokud odpověď zahrnuje exporty v CSV nebo noční dávkové úlohy, strávíte příští dva roky řešením okrajových případů.

Viděli jsme týmy, které se snažily naroubovat účetní nástroj orientovaný na uživatelské rozhraní na oboustranné tržiště, aby o osmnáct měsíců později potichu budovaly celé řešení znovu. Problémem téměř nikdy není fakturace. Je to hlavní účetní kniha (ledger), daňové režimy DPH pro jednotlivé země a párování plateb mezi harmonogramem výplat platformy a představou účetního systému o tom, kdy byly tržby zaúčtovány.

Tento průvodce představuje účetní API, která jsou pro tento úkol v EU aktuálně skutečně stavěná, jaké mají kompromisy a jak vybrat takové, jehož volby nebudete litovat.

Co pro tržiště skutečně znamená „API pro automatizaci účetnictví“

Pro tržiště není účetní API nástrojem pro vykazování. Je to primární zdroj pravdy o penězích. To mění požadavky:

• Skutečná podvojná účetní kniha (double-entry ledger), kterou nelze zpětně potichu upravovat. Ne tabulka faktur se souhrnným zobrazením.
• Logika DPH pro jednotlivé země, která rozumí režimům OSS, přenesení daňové povinnosti (reverse charge), B2B vs. B2C a pravidlům místa plnění. Ne pole pro daňovou sazbu.
• Párování výplat (reconciliation), které dokáže spárovat hromadný bankovní převod se stovkami souvisejících objednávek, vrácených peněz a poplatků.
• Idempotence u každého zápisového koncového bodu. Protože budete požadavky opakovat a nemůžete si dovolit duplicitní účetní zápisy.
• Webhooky pro změny stavu, aby vaše aplikace nemusela neustále zjišťovat dotazováním (polling), zda byla faktura zaplacena.
• Podpora pro více subjektů (multi-entity), protože většina tržišť skončí do tří let s lucemburskou holdingovou společností, operačním subjektem a jednou nebo dvěma dceřinými společnostmi v jiných zemích.

Pokud API tyto věci nezvládá nativně, skončíte u toho, že si je budete psát sami, čímž celý účel ztrácí smysl.

Možnosti, které stojí v roce 2026 za zvážení

Účetních nástrojů s přístupem přes API je dnes více než před třemi lety, ale těch, které jsou skutečně vhodné pro tržiště, zůstává málo. Většina z nich byla vytvořena pro účetnictví malých a středních podniků a API na ně bylo naroubováno dodatečně. Jen málokteré vzniklo s primárním důrazem na API (API-first).

Zde je pohled na náš užší výběr.

Nordlet

Nordlet je řešení, které týmům doporučujeme jako první, pokud stavějí tržiště nebo platformu v EU. Od počátku byl navržen jako API, nikoli jako produkt s uživatelským rozhraním a dodatečně přidanými koncovými body, přičemž shoda funkcí mezi aplikací a API je téměř stoprocentní. Jádro tvoří neměnná podvojná účetní kniha s vestavěným dodržováním předpisů DPH pro jednotlivé země, včetně ověřování VIES pro přeshraniční B2B transakce a generování registru i.SAF pro litevská daňová přiznání.

Co je pro tržiště v praxi důležité:

• Stylová SDK (včetně TypeScript SDK) a předvídatelné koncové body REST, takže zavedení nového backendového inženýra trvá hodiny, nikoli týdny.
• Podpora idempotentních klíčů u zápisů, což představuje rozdíl mezi spolehlivou integrací a hlášením podpory při každém výpadku sítě.
• Webhooky pro události typu sale_invoice.paid, takže vaše aplikace může reagovat v reálném čase na změny platebního stavu.
• Export SEPA pain.001 pro výplaty dodavatelům a prodejcům a párování bankovních transakcí jedním kliknutím pomocí chytrého párování (smart matching).
• Více firem pod jedním účtem s řízením přístupu na základě rolí (vlastník, správce, účetní, manažer, vývojář, čtenář), což je důležité při řízení skupinové struktury.
• Uzamykání období (period locking), takže uzavřené měsíce nelze potichu přepsat, což je přesně to, na co se váš auditor zeptá jako první.

Kompromis: Nordlet je aktuálně ve fázi designového partnera / předběžného přístupu (early access). Pokud potřebujete vyzrálý manuál pro tržiště se stovkami publikovaných případových studií, ten zatím nezískáte. Pokud chcete pracovat přímo s týmem, který staví potřebné stavební kameny, pak to dává smysl.

Xero API

Xero disponuje největším ekosystémem ze všech moderních účetních API a představuje rozumnou volbu pro přímočaré malé a střední podniky nebo jednoduchou integraci s platformou. Pro tržiště se však jeho struktura rychle stává nepraktickou. Jde v podstatě o produkt orientovaný na uživatelské rozhraní a pracovní postupy pro více subjektů zahrnují žonglování se samostatnými organizacemi namísto nativní skupinové struktury. Zpracování DPH je solidní pro Velkou Británii a použitelné pro EU, ale specifika jednotlivých zemí, jako je i.SAF nebo elektronická fakturace Peppol BIS 3.0, obvykle zůstávají mimo jádro a závisí na aplikacích třetích stran.

QuickBooks Online API

QuickBooks má silnou pozici v USA a zlepšující se pokrytí v EU, ale pro tržiště zaměřená na EU představuje špatné těžiště. Daňová logika je primárně přizpůsobena americké prodejní dani (sales tax), a přestože API je schopné, okrajové případy unijní DPH (limity OSS, přenesení daňové povinnosti ve 27 zemích) obvykle vyžadují vlastní middleware.

Sage / Sage Intacct

Sage se stále objevuje v diskusích o pořizování softwaru v EU, zejména tam, kde ho finanční týmy již znají. API existují, ale projevuje se na nich jejich věk. Webhooky v reálném čase jsou omezené, dokumentace pro vývojáře je napříč produkty nejednotná a předpoklad, že účetní bude u operací na konci měsíce vždy přítomen, neodpovídá tomu, jak funguje moderní produktový tým.

Odoo

Odoo představuje přijatelnou volbu, pokud chcete open-source ERP systém, který zahrnuje účetnictví, a nevadí vám provoz vlastní infrastruktury. API je komplexní, ale spíše široké než hluboké, takže se často integrujete s ERP systémem než se specializovaným účetním engine. Pro tržiště s vysokou provozní složitostí mimo finance (skladové hospodářství, výroba) to může dávat smysl. Pro čisté tržiště obvykle představuje větší rozsah, než potřebujete.

Starší nástroje specifické pro danou zemi

Ve většině zemí EU existuje alespoň jeden zavedený účetní produkt s částečným API. Často jsou levné, často je používají místní účetní, ale téměř nikdy nejsou postaveny pro programovou integraci v měřítku tržiště. Pokud jste malý lokální hráč, stačí to. Pokud plánujete za dva roky fungovat přeshraničně, nezačínejte zde.

Porovnání schopností

Následující tabulka odráží pouze to, co je přímo podporováno veřejnou produktovou dokumentací. Tam, kde nemáme přímé potvrzení schopností konkurence, to raději uvádíme, než abychom tipovali.

Schopnost	Nordlet	Xero API	QuickBooks API	Sage	Odoo
Architektura API-first (shoda funkcí app/API)	Ano	Ne (UI-first)	Ne (UI-first)	Částečně	Částečně
Neměnná podvojná účetní kniha	Ano	Veřejně nepotvrzeno	Veřejně nepotvrzeno	Veřejně nepotvrzeno	Veřejně nepotvrzeno
Unijní DPH pro jednotlivé země s ověřením VIES	Ano	Částečně	Omezeně	Neznámo	Částečně
Generování registru i.SAF (Litva)	Ano	Neznámo	Neznámo	Neznámo	Neznámo
Stylová SDK (včetně TypeScript)	Ano	Většinou třetí strany	Většinou třetí strany	Neznámo	Neznámo
Podpora idempotentních klíčů	Ano	Veřejně nepotvrzeno	Veřejně nepotvrzeno	Neznámo	Neznámo
Webhooky finančních událostí v reálném čase	Ano	Omezeně	Omezeně	Omezeně	Ano
Export SEPA pain.001	Ano	Přes aplikace	Veřejně nepotvrzeno	Neznámo	Ano
Více firem pod jedním účtem, RBAC	Ano	Více organizací (zvlášť)	Více organizací (zvlášť)	Ano	Ano
Uzamykání období	Ano	Ano	Ano	Ano	Ano
Bezheslové přihlášení	Ano	Není standardem	Není standardem	Není standardem	Není standardem

Řádky, kterým bychom při rozhodování o tržišti přikládali největší váhu, jsou neměnnost účetní knihy, hloubka DPH v konkrétních zemích, kde skutečně působíte, a idempotence. Všechno ostatní se dá obejít. Tyto tři věci se v případě své absence stávají trvalou přítěží.

Problém párování plateb, před kterým vás nikdo nevaruje

Každý zakladatel tržiště, se kterým jsme mluvili, podceňuje párování výplat. Vypadá to takto.

Za týden zpracujete 4 000 objednávek. Poskytovatel platebních služeb (PSP) vám v úterý zašle na bankovní účet paušální částku poníženou o poplatky, vrácené peníze z předchozího období a zpětné platby (chargebacks). Účetní systém potřebuje vědět: kterých objednávek se tento převod týká, jaká část představuje vaše tržby a jaká závazek vůči prodejci, jaká DPH byla vybrána z vaší provize a co se stane, když bude jedna z těchto objednávek za tři týdny vrácena.

Pokud vaše účetní API nedokáže načíst soubor s vyrovnáním od PSP a spárovat jej s fakturami lépe než pouhým porovnáním přesné částky, nakonec zaměstnáte člověka, jehož celou náplní práce bude párování tabulek v Excelu. Viděli jsme to v společnostech dosahujících osmifigurových obratů v GMV.

Funkce chytrého párování a párování faktur jedním kliknutím v Nordletu je vytvořena přesně pro tento scénář. Xero to zvládá pomocí doplňků. Integrace s QuickBooks obvykle vyžadují middleware, jakmile objem přesáhne několik tisíc transakcí měsíčně.

DPH: důvod, proč většina tržišť podceňuje rozsah práce

DPH v EU pro tržiště je skutečně složitá, a to ne proto, že by pravidla byla nejasná. Je to proto, že jich je hodně a vzájemně se ovlivňují.

Od reformy elektronického obchodu v roce 2021 a pravidel o považování platformy za dodavatele (deemed supplier) může být platforma pro účely DPH považována za dodavatele u určitých transakcí, i když nenabývá vlastnické právo ke zboží. To znamená, že samotné tržiště má povinnosti k DPH ohledně podkladového prodeje, nejen ze své provize. Přiznání OSS, IOSS pro zboží do 150 EUR ze zemí mimo EU, registrační limity pro jednotlivé země, přenesení daňové povinnosti u B2B služeb, ověřování VIES pro přeshraniční B2B: všechno musí být správně a všechno se musí odrazit v účetní knize od okamžiku zaúčtování transakce, nikoli se zpětně rekonstruovat na konci čtvrtletí.

Účetní API, které vám poskytne pole vat_rate a tím to pro něj končí, selže při vaší první kontrole. Potřebujete logiku pro jednotlivé země, ověření VIES u DIČ zákazníka v okamžiku transakce a automatické generování místních formátů výkazů (i.SAF v Litvě, varianty SAF-T jinde).

V této oblasti mají novější nástroje s primárním důrazem na API (API-first) vytvořené v EU výrazný náskok před staršími mezinárodními produkty. Předpisy jsou natolik blízké domovu, že týmy tvořící software v nich žijí.

Co bychom udělali jako první

Pokud bychom zítra zakládali tržiště v EU a vybírali účetní infrastrukturu, postupovali bychom v tomto pořadí:

1. Nejprve mapujte své daňové expozice, ne nakonec. Vyjmenujte všechny země, do kterých budete v prvním roce prodávat, zda jsou transakce B2B nebo B2C, a zda se uplatňují pravidla považování za dodavatele. To vám řekne, co musí účetní systém skutečně zvládnout.
2. Otestujte účetní knihu a tok párování v sandboxu. Ne fakturaci. Fakturu dokáže vygenerovat každý. Prožeňte sandboxem reálný objem transakcí za jeden týden a sledujte, co se stane na konci měsíce.
3. Zkontrolujte smlouvu API ohledně idempotence a webhooků. Pokud nemůžete bezpečně opakovat požadavek nebo se přihlásit k odběru změn stavu, stavíte křehkou infrastrukturu.
4. Promluvte si s tím, kdo vám skutečně uzavře účetní knihy. Pokud váš účetní nezíská potřebné sestavy v požadovaném formátu, je automatizace nadřazených procesů k ničemu.
5. Zvolte dodavatele, jehož plánu rozvoje (roadmap) můžete ovlivnit. Pro tržiště v počáteční fázi to znamená víc než odškrtnutí každého políčka s funkcemi. Ujednání pro designové partnery existují z nějakého důvodu.

FAQ

Skutečně potřebuji podvojnou účetní knihu, nebo stačí tabulka transakcí?

Tabulka transakcí funguje do chvíle, než poprvé potřebujete auditorovi vysvětlit nesrovnalost nebo přepracovat minulé období. Podvojné účetnictví není reliktem starého účetnictví. Je to důvod, proč se vám knihy rovnají a chyby se projeví okamžitě, namísto toho, aby se potichu kumulovaly.

Mohu místo účetního API používat výkazy od Stripe?

Stripe je zpracovatel plateb. Jeho výkazy jsou v pořádku pro párování plateb ze Stripe. Nepoužívá podvojné účetnictví, nezpracovává tržby z jiných zdrojů než ze Stripe a nevytváří povinné zákonné výkazy. Používejte jej vedle účetního API, nikoli místo něj.

Jak zvládnu více zemí bez registrace všude?

Pro B2C prodej zboží a služeb v rámci EU vám režim One Stop Shop (OSS) umožňuje podávat přiznání v jedné zemi pro prodeje v celém bloku, až do určitých limitů a s určitými výjimkami. Vaše účetní API musí každou transakci správně zařadit, aby přiznání k OSS bylo přesné. Jde o otázku schopností, nikoli o obcházení pravidel.

Je účetnictví postavené na API-first pro malé tržiště příliš složité?

Pokud jste malí a očekáváte, že malí zůstanete, tradiční nástroj s lehkým API postačí. Pokud očekáváte růst, včasné zakomponování účetnictví do produktu je mnohem levnější než pozdější migrace z nástroje orientovaného na uživatelské rozhraní. Náklady na změnu účetní infrastruktury patří ve firemním stacku k nejvyšším.

Co se stane, když dodavatel změni své API?

Před podpisem smlouvy se zeptejte na zásady ukončování podpory (deprecation), verzování a způsob řešení změn, které by porušily zpětnou kompatibilitu (breaking changes). Každý seriozní produkt s důrazem na API by měl mít jasnou odpověď. Pokud ji nemá, odpovědí je to samo o sobě.