Nordlet

← Blog

Najlepšie účtovné automatizačné API pre trhoviská v EÚ (2026)

Pohľad odborníka na to, ktoré účtovné API skutočne fungujú, keď presúvate peniaze cez hranice, daňové režimy DPH a tisíce malých transakcií denne.

Nordlet Team · · 10 min. čítania

Najrýchlejší spôsob, ako zistiť, či bolo účtovné API vytvorené pre trhoviská (marketplaces), je spýtať sa, čo sa stane, keď litovský kupujúci zaplatí nemeckému predajcovi za produkt odoslaný z poľského skladu a platforma si zoberie 12-percentný podiel plus poplatok za spracovanie platby. Ak odpoveď zahŕňa exporty CSV alebo nočnú dávkovú úlohu (batch job), strávite nasledujúce dva roky opravovaním okrajových prípadov (edge cases).

Sledovali sme tímy, ktoré sa pokúšali narýchlo pripojiť účtovný nástroj orientovaný na používateľské rozhranie k obojstrannému trhovisku (two-sided marketplace) a o osemnásť mesiacov neskôr potichu prerábali celý systém od základu. Problém takmer nikdy nie je v samotnej fakturácii. Je ním hlavná kniha, uplatňovanie DPH v jednotlivých krajinách a párovanie (reconciliation) medzi výplatným kalendárom platformy a predstavou účtovného systému o tom, kedy boli tržby zarobené.

Toto je sprievodca účtovnými API, ktoré sú na túto prácu v EÚ momentálne skutočne pripravené, aké prinášajú kompromisy a ako si vybrať bez toho, aby ste sa unáhlili a neskôr to ľutovali.

Čo musí „účtovné automatizačné API“ pre trhovisko reálne znamenať

Pre trhovisko nie je účtovné API reportovacím nástrojom. Je to jediný zdroj pravdy o peniazoch (source of truth). To mení požiadavky:

  • Skutočná podvojná hlavná kniha (double-entry ledger), ktorú nemožno dodatočne potichu upravovať. Žiadna tabuľka faktúr so zobrazením súčtov.
  • Logika DPH pre každú krajinu, ktorá rozumie režimu OSS, prenosu daňovej povinnosti (reverse charge), vzťahom B2B verzus B2C a pravidlám miesta dodania. Žiadne obyčajné pole pre sadzbu dane.
  • Párovanie výplat (payout reconciliation), ktoré dokáže spárovať hromadný bankový prevod so stovkami súvisiacich objednávok, vrátení peňazí a poplatkov.
  • Idempotencia pre každý koncový bod zápisu (write endpoint). Pretože budete vykonávať opakované pokusy (retries) a nemôžete si dovoliť duplicitné účtovné zápisy.
  • Webhooky pre zmeny stavov, aby váš produkt nemusel neustále kontrolovať (polling), či bola faktúra zaplatená.
  • Podpora viacerých subjektov (multi-entity), pretože väčšina trhovísk skončí do troch rokov s lucemburskou holdingovou spoločnosťou, operačným subjektom a jednou či dvoma dcérskymi spoločnosťami v iných krajinách.

Ak API tieto veci nezvláda natívne, skončíte pri ich vlastnom vývoji, čím stratíte pôvodný zmysel jeho použitia.

Možnosti, ktoré sa oplatí brať vážne v roku 2026

Účtovných nástrojov s prístupom cez API je dnes viac ako pred tromi rokmi, no počet tých, ktoré sa skutočne hodia pre trhovisko, zostáva malý. Väčšina bola vytvorená pre účtovníctvo malých a stredných podnikov (SMB) a API na ne bolo napojené dodatočne. Len máloktí išli cestou "API-first".

Tu je náš pohľad na užší výber.

Nordlet

Nordlet je riešenie, ktoré tímom odporúčame ako prvé, ak budujú trhovistú alebo platformu v EÚ. Od začiatku bolo navrhnuté ako API a nie ako produkt s používateľským rozhraním, ku ktorému neskôr pribudli koncové body, pričom zhoda funkcií medzi aplikáciou a API je takmer úplná. Jadro tvorí nemenná podvojná hlavná kniha s integrovaným súladom s DPH pre jednotlivé krajiny vrátane overovania VIES pre cezhraničné B2B transakcie a generovania i.SAF registrov pre litovské daňové priznania.

Čo je pre trhovisko prakticky dôležité:

  • Typové SDK (vrátane TypeScript SDK) a predvídateľné koncové body REST, takže zaškolenie nového backendového inžiniera trvá hodiny, nie týždne.
  • Podpora kľúčov idempotencie (idempotency-key) pri zápisoch, čo predstavuje rozdiel medzi spoľahlivou integráciou a ticketom na podporu zakaždým, keď zakolíše sieť.
  • Webhooky pre udalosti ako sale_invoice.paid, vďaka ktorým môže váš produkt reagovať v reálnom čase na zmeny stavu platieb.
  • Export SEPA pain.001 pre výplaty dodávateľom a predajcom a párovanie bankových výpisov jedným kliknutím s inteligentným priradením.
  • Viacero spoločností pod jedným účtom s prístupom na základe rolí (vlastník, administrátor, účtovník, manažér, vývojár, pozorovateľ), čo je dôležité pri prevádzkovaní skupinovej štruktúry.
  • Uzamykanie účtovných období (period locking), takže uzavreté mesiace nemožno potichu prepísať, čo je presne to, na čo sa váš audítor spýta ako prvé.

Kompromis: Nordlet je aktuálne vo fáze dizajnérskeho partnera a skorého prístupu (early access). Ak potrebujete overené postupy pre trhoviská so stovkami publikovaných prípadových štúdií, tie zatiaľ nezískate. Ak chcete pracovať priamo s tímom, ktorý buduje presne tie stavebné prvky, aké potrebujete, toto je ten správny smer.

Xero API

Xero má najväčší ekosystém zo všetkých moderných účtovných API a je rozumnou voľbou pre jednoduché SMB alebo ľahkú integráciu platformy. Pre trhovisko sa však jeho štruktúra rýchlo stáva nepraktickou. V podstate ide o produkt orientovaný na používateľské rozhranie a pracovné postupy pre viacero subjektov zahŕňajú žonglovanie s oddelenými organizáciami namiesto natívnej skupinovej štruktúry. Spracovanie DPH je solídne pre Veľkú Britániu a použiteľné pre EÚ, no špecifiká jednotlivých krajín, ako napríklad i.SAF alebo e-fakturácia Peppol BIS 3.0, zvyčajne zostávajú mimo jadra a závisia od aplikácií tretích strán.

QuickBooks Online API

QuickBooks má silné zastúpenie v USA a zlepšujúce sa pokrytie v EÚ, no pre trhovisko zamerané na EÚ predstavuje nesprávne ťažisko. Daňová logika je postavená primárne okolo americkej dane z predaja (sales tax), a hoci API je schopné, okrajové prípady DPH v EÚ (limity OSS, prenos daňovej povinnosti v 27 krajinách) si zvyčajne vyžadujú vlastný middlewarový softvér.

Sage / Sage Intacct

Sage sa stále objavuje v diskusiách o obstarávaní v EÚ, najmä tam, kde ho finančné tímy už poznajú. API existujú, ale ukazujú svoj vek. Webhooky v reálnom čase sú obmedzené, dokumentácia pre vývojárov je naprieč produktmi nevyrovnaná a predpoklad, že účtovník bude zapojený do operácií na konci mesiaca, nezodpovedá tomu, ako funguje moderný tím platformy.

Odoo

Odoo je vhodnou voľbou, ak chcete open source ERP, ktoré zahŕňa účtovníctvo, a vyhovuje vám správa infraštruktúry. API je komplexné, ale skôr všeobecné než hĺbkové, takže často integrujete samotné ERP a nie špecializovaný účtovný engine. Pre trhoviská s vysokou prevádzkovou komplexnosťou mimo financií (skladové zásoby, výroba) to môže byť vhodné. Pre čisté trhovisko je to zvyčajne väčší rozsah, než aký potrebujete.

Staršie lokálne nástroje

Vo väčšinách krajín EÚ existuje aspoň jeden tradičný účtovný produkt s čiastočným API. Často sú lacné, často ich používajú miestni účtovníci a takmer nikdy nie sú postavené na programovaticú integráciu v rozsahu trhoviska. Ak ste malý lokálny hráč, postačí to. Ak plánujete o dva roky expandovať do zahraničia, nezačínajte tu.

Porovnanie funkcií

Nasledujúca tabuľka odráža iba to, čo je priamo podporované vo verejnej produktovej dokumentácii. Tam, kde nemáme priame potvrdenie schopnosti konkurenta, uvádzame to na pravú mieru namiesto hádania.

Funkcia Nordlet Xero API QuickBooks API Sage Odoo
Architektúra API-first (zhoda funkcií app/API) Áno Nie (UI-first) Nie (UI-first) Čiastočne Čiastočne
Nemenná podvojná hlavná kniha Áno Verejne nepotvrdené Verejne nepotvrdené Verejne nepotvrdené Verejne nepotvrdené
EÚ DPH pre jednotlivé krajiny s overovaním VIES Áno Čiastočne Obmedzene Neznáme Čiastočne
Generovanie i.SAF registrov (Litva) Áno Neznáme Neznáme Neznáme Neznáme
Typové SDK (vrátane TypeScript) Áno Väčšinou tretie strany Väčšinou tretie strany Neznáme Neznáme
Podpora kľúčov idempotencie Áno Verejne nepotvrdené Verejne nepotvrdené Neznáme Neznáme
Webhooky finančných udalostí v reálnom čase Áno Obmedzene Obmedzene Obmedzene Áno
Export SEPA pain.001 Áno Cez aplikácie Verejne nepotvrdené Neznáme Áno
Viac spoločností pod jedným účtom, RBAC Áno Viac organizácií (oddelené) Viac organizácií (oddelené) Áno Áno
Uzamykanie období Áno Áno Áno Áno Áno
Prihlásenie bez hesla Áno Nie je štandardom Nie je štandardom Nie je štandardom Nie je štandardom

Riadky, ktorým by sme pri rozhodovaní o trhovisku prikladali najväčšiu váhu, sú nemennosť hlavnej knihy, hĺbka DPH v konkrétnych krajinách, kde skutočne pôsobíte, a idempotencia. Všetko ostatné sa dá vyriešiť obklikou. Ak tieto tri veci chýbajú, stávajú sa trvalou príťažou.

Problém s párovaním, pred ktorým vás nikto nevaruje

Každý zakladateľ trhoviska, s ktorým sme hovorili, podceňuje párovanie výplat. Tu je typický vzorec.

Za týždeň spracujete 4 000 objednávok. V utorok vám poskytovateľ platobných služieb (PSP) uhradí na účet hromadnú platbu mínus jeho poplatky, mínus vrátené platby z predchádzajúceho obdobia a mínus sporné platby (chargebacks). Váš účtovný systém potrebuje vedieť: ktorej objednávke tento prevod zodpovedá, aká časť predstavuje váš príjem verzus záväzok voči predajcovi, aká DPH bola vybratá z vašej provízie a čo sa stane, keď bude jedna z týchto objednávok o tri týždne stornovaná a peniaze budú vrátené.

Ak vaše účtovné API nedokáže načítať súbor vyrovnaní od PSP a spárovať ho s faktúrami niečím lepším než len porovnaním presných súm, najmete si niekoho, ktorého celou náplňou práce bude párovanie tabuliek. Videli sme to v spoločnostiach s obratom v miliónoch (eight figures in GMV).

Inteligentné párovanie a párovanie faktúr jedným kliknutím v systéme Nordlet sú vytvorené presne pre tento účel. Xero to dokáže pomocou doplnkov. Integrácie QuickBooks si zvyčajne vyžadujú middleware, akonáhle objem prekročí niekoľko tisíc transakcií mesačne.

DPH: dôvod, prečo väčšina trhovísk podceňuje rozsah

EÚ DPH pre trhoviská je skutočne zložitá a nie preto, že by pravidlá boli nejasné. Je to preto, že je ich veľa a vzájomne sa ovplyvňujú.

Od reforiem elektronického obchodu z roku 2021 a pravidiel o považovaní platformy za dodávateľa (deemed supplier rules) môže byť platforma pri určitých transakciách považovaná za dodávateľa na účely DPH, a to aj vtedy, keď nad tovarom nenadobudne vlastnícke právo. To znamená, že samotné trhovisko má povinnosti k DPH z podkladového predaja, nielen z vlastnej provízie. Priznania OSS, IOSS pre tovar do 150 EUR z krajín mimo EÚ, prahové hodnoty pre registráciu v jednotlivých krajinách, prenos daňovej povinnosti pri službách B2B, overovanie VIES pre cezhraničné B2B: všetko musí byť správne a všetko sa musí odzrkadliť v hlavnej knihe od momentu zaevidovania transakcie, nie sa rekonštruovať na konci štvrťroka.

Účtovné API, ktoré vám poskytne pole vat_rate a považuje vec za vybavenú, pri vašom prvom audite zlyhá. To, čo potrebujete, je logika pre jednotlivé krajiny, overovanie VIES pre DIČ zákazníka v čase transakcie a automatické generovanie lokálnych formátov výkazov (i.SAF v Litve, varianty SAF-T inde).

Toto je oblasť, kde nástroje typu API-first vytvorené nedávno v EÚ bývajú výrazne popred staršími medzinárodnými produktmi. Predpisy sú dostatočne blízko domova, takže tímy, ktoré softvér vytvárajú, v nich priamo žijú.

Čo by sme urobili ako prví

Ak by sme zajtra zakladali trhovistikú platformu v EÚ a vyberali účtovnú infraštruktúru, postupovali by sme v tomto poradí:

  1. Najskôr si mapujte svoju daňovú expozíciu, nie na konci. Vymedzte každú krajinu, do ktorej budete v prvom roku predávať, či sú transakcie B2B alebo B2C a či sa uplatňujú pravidlá považovania za dodávateľa. To vám povie, čo musí účtovný systém reálne zvládnuť.
  2. Vytvorte prototyp hlavnej knihy a procesu párovania v sandboxovom prostredí. Nie fakturáciu. Faktúru dokáže vygenerovať hocikto. Prepusťte cez sandbox objem reálnych transakcií za jeden týždeň a sledujte, čo sa stane na konci mesiaca.
  3. Skontrolujte zmluvu API na idempotenciu a webhooky. Ak nemôžete bezpečne zopakovať požiadavku alebo sa prihlásiť na odber zmenových stavov, budujete krehkú infraštruktúru.
  4. Porozprávajte sa s tým, kto vám skutočne uzavrie účtovné knihy. Ak váš účtovník nedokáže získať správy, ktoré potrebuje, vo formáte, aký vyžaduje, automatizácia vyššie v reťazci je bezpredmetná.
  5. Vyberte si dodávateľa, ktorého plán vývoja (roadmap) viete ovplyvniť. Pre začínajúce trhovisko to zaváži viac než zaškrtnutie každého políčka s funkciou dnes. Dohody o dizajnérskom partnerstve existujú z nejakého dôvodu.

FAQ

Naozaj potrebujem podvojnú hlavnú knihu, alebo stačí tabuľka transakcií?

Tabuľka transakcií funguje dovtedy, kým prvýkrát nepotrebujete vysvetliť nesúlad audítorovi alebo spätne upraviť minulé obdobie. Podvojné účtovníctvo nie je pozostatok starého divadla. Je to dôvod, prečo vám sedia knihy a prečo sa chyby prejavia okamžite namiesto toho, aby sa potichu nabaľovali.

Môžem namiesto účtovného API použiť reportovanie od Stripe?

Stripe je platobný procesor. Jeho reporty sú v poriadku na párovanie platieb zo Stripe. Nevykonáva podvojné účtovníctvo, nespracováva tržby z iných zdrojov ako zo Stripe a nevytvára povinné zákonné výkazy. Používajte ho popri účtovnom API, nie namiesto neho.

Ako zvládnuť viaceré krajiny bez registrácie všade?

Pri predaji tovaru a služieb koncovým zákazníkom (B2C) v rámci EÚ vám schéma Jednotného kontaktného miesta (OSS) umožňuje podať jediné priznanie v jednej krajine za predaje v celom bloku, až do určitých limitov a s určitými výnimkami. Vaše účtovné API musí správne kategorizovať každú transakciu, aby bolo priznanie OSS presné. Toto je otázka schopností, nie obchádzania.

Je účtovníctvo postavené na API pre malé trhovisko zbytočný luxus?

Ak ste malí a plánujete takými zostať, tradičný nástroj s ľahkým API postačí. Ak plánujete rásť, včasné zabudovanie účtovníctva do vášho produktu je oveľa lacnejšie než neskoršia migrácia z nástroja postaveného na používateľskom rozhraní. Náklady na zmenu účtovnej infraštruktúry patria k najvyšším v technologickom zásobe (stack) firmy.

Čo sa stane, ak dodávateľ zmení svoje API?

Pred podpisom zmluvy sa informujte o pravidlách preukončovania (deprecation policies), verzovaní a o tom, ako riešia zmeny narúšajúce spätnú kompatibilitu (breaking changes). Každý seriózny produkt typu API-first by mal mať jasnú odpoveď. Ak ju nemá, to je tá odpoveď.