Čo je API podvojného účtovníctva pre preoviská (marketplaces)?
API podvojného účtovníctva zaznamenáva finančné toky na preoviskách vo forme vyrovnaných, nezmeniteľných účtovných zápisov, takže vždy viete, kto a prečo vám koľko dlhuje.
Preovisko (marketplace) môže mať tabuľku orders v poriadku a napriek tomu vykazovať nesprávne finančné výsledky. V objednávke svieti stav „zaplatené“. Na paneli predajcu sa zobrazuje zostatok. Žiadna položka v tejto tabuľke však nepreukazuje, koľko hotovosti platforma reálne drží, koľko dlhuje jednotlivým predajcom, aká časť platby predstavuje výnos z provízie alebo koľko DPH je potrebné odviesť. API podvojného účtovníctva (double-entry ledger API) existuje presne na to, aby tieto finančné dopady zaznamenávalo správne, pričom každá transakcia musí byť vyrovnaná.
Zjednodušene povedané: API podvojného účtovníctva je programovateľný účtovný systém. Vaša aplikácia doň odošle finančnú udalosť, akou je napríklad inkasovaná platba alebo schválená výplata peňazí (payout), a účtovná kniha (ledger) túto udalosť zapíše ako denník (journal) s rovnakými má dať a dal na príslušných účtoch. Peniaze samy o sebe nepresúva. Zaznamenáva pravdu o peniazoch, ktoré sa presunuli inde.
Čo v tomto kontexte znamená „podvojné účtovníctvo“
Účtovná kniha (ledger) je záznam o zmenách na účtoch, nie tabuľka uchovávajúca aktuálny zostatok. Fungujúca účtovná kniha stavia na troch prepojených pilieroch:
- Účet (account): pomenovaná finančná pozícia, napríklad pohľadávka voči platobnej bráne, záväzok voči predajcovi, výnos z provízií alebo záväzok z DPH.
- Transakcia (denník / journal): jedna atómová finančná udalosť obsahujúca viaceré vyrovnané riadky.
- Záznam (posting): jeden riadok má dať alebo dal v rámci danej transakcie.
Nemenné pravidlo, ktoré drží celý systém pohromade, je jednoduché: celková suma má dať sa musí rovnať celkovej sume dal, a to pri každej transakcii a v každej mene. API podvojného účtovníctva zvyčajne odmietne zapísať nevyrovnanú transakciu skôr, ako sa dostane do úložiska. Dokumentácia spoločnosti Modern Treasury definuje transakciu v účtovnej knihe ako operáciu zahŕňajúcu dva alebo viac účtov s aspoň jednou položkou má dať a jednou dal v rovnakých celkových sumách, pričom zaúčtovanú transakciu považuje za nemennú.
Podvojnosť neznamená presne dva riadky. Jediný predaj na preovisku si často vyžaduje jednu položku má dať a niekoľko položiek dal. Práve tomu ľudia často nerozumejú.
Prečo preoviská potrebujú účtovnú knihu namiesto obyčajnej tabuľky platieb
Preovisko spravuje hneď niekoľko finančných vzťahov naraz. Kupujúci platí. Platobná brána vysporiada transakciu. Platforma môže finančné prostriedky dočasne kontrolovať. Predajca získa svoj podiel. Platforma si ponechá províziu. Vzniká daňová povinnosť. Časť peňazí môže byť zadržaná ako rezerva. Neskôr sa vyplatia peniaze predajcovi a vrátenia peňazí (refunds) alebo reklamácie (chargebacks) časť týchto operácií stornujú.
Tabuľka payments vám síce povie obchodný stav objednávky, no spoľahlivo vám neodpovie na otázky:
- aká je výška pohľadávok voči platobnej bráne alebo hotovosti,
- koľko sa dlhuje jednotlivým predajcom,
- aká časť výnosov patrí platforme,
- aká je výška DPH na úhradu a v ktorej krajine,
- aká suma je vyhradená na krytie vrátení peňazí alebo sporov,
- či výplata peňazí (payout) znížila správny záväzok voči predajcovi,
- či vyúčtovania platobnej brány zodpovedajú očakávaniam platformy.
Sprievodca API podvojného účtovníctva pre účtovníctvo preovísk od spoločnosti Nordlet kreslí jasnú čiaru: tabuľky v aplikácii popisujú stav produktu, zatiaľ čo účtovná kniha zaznamenáva finančné dôsledky tohto stavu. Zdôrazňuje tiež fakt, že reporty od platobných brán sú len vstupmi na odsúhlasovanie, nie kompletným podvojným účtovníctvom.
Ukážka reálneho predaja na preovisku
Predpokladajme, že kupujúci zaplatí 100 €, predajca má nárok na 85 € a provízia platformy je 15 €. Pre väčšiu prehľadnosť vynechajme DPH a poplatky platobnej brány.
| Účet | Má dať (Debit) | Dal (Credit) | Dôvod |
|---|---|---|---|
| Pohľadávka voči platobnej bráne | 100 € | Platobná brána dlhuje platforme inkasovanú platbu | |
| Záväzok voči predajcovi | 85 € | Platforma dlhuje predajcovi | |
| Výnosy z provízií | 15 € | Platforma zarobila na provízii | |
| Spolu | 100 € | 100 € | Vyrovnané |
Dôležitá klasifikácia spočíva v tom, že 85 € dlhovaných predajcovi predstavuje záväzok, nie výnos platformy. Podľa koncepčného rámca IFRS je záväzok súčasnou povinnosťou previesť ekonomický zdroj. Preovisko by nemalo vykazovať celkový príjem predajcu z predaja ako svoj vlastný príjem len preto, že kupujúci platil prostredníctvom neho. Či vystupujete ako sprostredkovateľ, komisionár alebo považovaný dodávateľ (deemed supplier), mení spôsob účtovania, ale samotný mechanizmus účtovnej knihy zostáva rovnaký.
Keď predajcovi vznikne nárok na výplatu, nevzniká žiadny nový výnos. Vy len vyrovnáte záväzok:
| Účet | Má dať (Debit) | Dal (Credit) |
|---|---|---|
| Záväzok voči predajcovi | 85 € | |
| Banka alebo zúčtovací účet výplat | 85 € | |
| Spolu | 85 € | 85 € |
Ak platobná brána pred vyúčtovaním strhne poplatok 3 €, peňažný tok sa premení na trojriadkový denník: 97 € na bankovú hotovosť, 3 € do nákladov na spracovanie platieb a 100 € von z pohľadávok voči platobnej bráne. Každá zmena pozície má svoj zdroj aj cieľ.
Ako API funguje krok za krokom
1. Vaša aplikácia detekuje obchodnú udalosť. Platba je inkasovaná, objednávka vybavená, výplata schválená, vrátenie peňazí spracované, otvorený sporný prípad (chargeback) alebo dorazilo vyúčtovanie. Vaša databáza stále spravuje prevádzkový stav. Účtovná kniha zaznamenáva peňažný dopad.
2. Odošlete štruktúrovanú požiadavku. Zvyčajne obsahuje typ udalosti, sumu a menu, ID objednávky alebo platby, identifikátory kupujúceho a predajcu, províziu, daňové údaje, dotknuté účty, dátum uskutočnenia účtovného prípadu a dátum zaúčtovania, idempotentný kľúč a metadáta odkazujúce na záznamy v platobnej bráne a produkte. Príklad verejného API spoločnosti Nordlet ukazuje koncepčnú žiadosť o predaj s ID predajcu, typom predaja, sumou, menou, krajinou DPH a sadzbou DPH.
3. API vykoná validáciu. Skontroluje, či má dať a dal súhlasia, či účty existujú a je možné na ne účtovať, či je mena podporovaná, či suma správne pracuje s drobnými mincovými jednotkami, či sa idempotentný kľúč nepoužil opakovane pre iný výsledok, či je účtovné obdobie otvorené a či sú prítomné povinné metadáta. Neúspešná kontrola nezanechá žiadne čiastočné záznamy v denníku.
4. Vykoná sa atómový zápis. Celá transakcia sa zapisuje ako jedna nedeliteľná jednotka. Nikdy by sa nemalo stať, že sa zapíše strana má dať, zatiaľ čo zodpovedajúca strana dal zlyhá. V prípade preoviska by čiastočné rozdelenie mohlo vytvoriť zdanlivý zostatok predajcu bez zodpovedajúcej hotovosti alebo zaúčtovať províziu bez záväzku voči predajcovi.
5. Zostatky a reporty sa odvíjajú od účtovnej knihy. Po zaúčtovaní môžete čítať zostatky na účtoch, čakajúce a dostupné zostatky predajcov, predvvahu (trial balance), aktivitu na hlavnej knihe, súhrny DPH a historické zostatky k určitému dátumu v minulosti. Zostatok predajcu by sa mal dať opätovne vytvoriť zo záznamov, nie spoliehať sa na meniteľné pole v databáze.
6. Webhooky informujú váš produkt. Udalosti ako sale_invoice.paid, zaúčtovaný denník, dostupná výplata peňazí alebo výnimka pri odsúhlasovaní vám budú doručené prostredníctvom webhookov. Spracujte ich idempotentne. Webhook je notifikácia, nie povolenie aplikovať tú istú finančnú udalosť druhýkrát. API konvencie podrobne pokrývajú rozsahy oprávnení (scopes), idempotentné kľúče, štruktúry chýb a podpisovanie webhookov.
Zostatky predajcov nie sú len jedno číslo
Väčšina preovísk má problémy preto, že zostatok predajcu chápe ako jedinú číselnú hodnotu. Peniaze by mali prechádzať rôznymi stavmi:
| Stav | Význam |
|---|---|
| Čakajúce (Pending) | Predajca môže mať na ne nárok, ale podmienky na uvoľnenie nie sú splnené |
| Dostupné (Available) | Pripravené na výplatu |
| Rezervované (Reserved) | Zadržané na krytie vrátení peňazí, reklamácií alebo sporov |
| Vyplatené (Paid out) | Záväzok vyrovnaný prevodom |
| Záporné (Negative) | Vrátené platby, poplatky alebo reklamácie presahujú dostupné prostriedky |
Tento model odrážajú aj modely platobných brán. Oddelené toky poplatkov a prevodov v Stripe umožňujú platforme zaťažiť vlastný účet a následne previesť časti na prepojené účty, pričom poplatky, vrátené platby a reklamácie zaťažujú zostatok platformy. Model preoviska v Adyen zas rozlišuje účty zostatkov používateľov, ktoré držia finančné prostriedky až do výplaty, od účtu zodpovednostného zostatku, ktorý dokáže absorbovať záporné zostatky z vrátených platieb alebo reklamácií. Sú to užitočné vstupy pre vašu účtovnú knihu, nepredstavujú však váš kompletný účtovný model.
Výplaty a zárobky predajcov prebiehajú v rôznych časoch
Predajca môže zarobiť peniaze v pondelok a výplatu dostať až nasledujúci pondelok. Medzi týmito bodmi sa objednávka vybaví, podrží sa rezerva, vytvorí sa dávka výplat, platobná brána ju vyúčtuje po odpočítaní poplatkov a na bankový účet dorazí vklad. Účtovná kniha musí zachovať každú jednu fázu namiesto toho, aby prepísala objednávku konečným stavom „zaplatené“. Práve to vám umožňuje vysvetliť časové rozdiely medzi aktivitou objednávok, nárokom predajcu, zúčtovaním, začatím výplaty a prijatím peňazí v banke.
Vrátenie peňazí a reklamácie: stornujte, neprepisujte
Vrátenie peňazí (refunds) a reklamácie (chargebacks) sú nové udalosti prepojené s pôvodnou platbou. V nezmeniteľnej účtovnej knihe (immutable ledger) robíte opravy pomocou stornovacieho záznamu, za ktorým nasleduje opravený záznam, takže originál zostáva viditeľný na účely auditu. Modern Treasury považuje zaúčtované transakcie za nemenné a podporuje idempotentné kľúče, aby sa zabránilo duplicitným objektom pri opakovaných pokusoch.
Vrátenie peňazí zvyčajne znižuje hotovosť alebo pohľadávky voči kupujúcemu, stornuje záväzok voči predajcovi, v závislosti od pravidiel môže stornovať časť provízie, upravuje daň a môže čerpať z rezervy na vrátenie peňazí. Reklamácia znižuje hotovosť alebo pohľadávky voči platobnej bráne, môže znova otvoriť sumu dlhovanú predajcom alebo platformou, zaznamenáva sporný náklad a poplatok platobnej brány a presúva finančné prostriedky cez rezervný účet.
Odsúhlasovanie (reconciliation): prepojenie účtovnej knihy so skutočnými peniazmi
Útovná kniha môže byť vnútorne vyrovnaná, a napriek tomu vykazovať nesprávne údaje vo vzťahu k vonkajšiemu svetu. Odsúhlasovanie porovnáva interné záznamy s externými dôkazmi: reportmi o zúčtovaní z platobných brán, výpismi z banky, súbormi výplat a záznamami o vrátení peňazí a sporoch.
Fungujúci proces vyzerá nasledovne:
- Importujte zúčtovaciu alebo bankovú dávku.
- Priradíte každý riadok k objednávke, platbe, vráteniu peňazí, poplatku, výplate alebo sporu.
- Porovnajte očakávanú hrubú sumu, zrážky, rezervy a čistú sumu.
- Zaúčtujte potvrdené pohyby do účtovnej knihy.
- Nepárové položky presmerujte na určený prechodný účet (suspense account).
- Preskúmajte výnimky.
- Uzavrite obdobie.
Materiály spoločnosti Nordlet o odsúhlasovaní popisujú presne tento postup - import zúčtovacích dávok, párovanie riadkov platieb a vrátených peňazí a smerovanie nepárovaných príjmov na prechodný účet namiesto hádania faktúry. Dve kontroly sú kľúčové a ani jedna nenahrádza tú druhú: validácia podvojného účtovníctva sa pýta, či je každý denník vyrovnaný, zatiaľ čo odsúhlasovanie sa pýta, či súhlasí s platobnou bránou, bankou a obchodnou udalosťou.
Konštrukčné detaily, ktoré rozhodujú o úspechu
Idempotencia. Prepojte kľúč so stabilnou udalosťou, napríklad payment_captured:pi_123. Opakovaný pokus vráti pôvodný výsledok, nevytvorí druhý denník.
Atómia. Všetky riadky jednej udalosti sa zaúčtujú naraz, alebo sa nezaúčtuje žiaden.
Nemennosť a storná. Zaúčtovanú históriu nie je možné upravovať bežnými aktualizáciami. Opravy vytvárajú prepojené záznamy, ktoré zachovávajú pôvodnú sumu, dátum, klasifikáciu, dôvod a autora.
Presné peniaze. Žiadne binárne desatinné čísla s plávacou rádovou čiarkou (floating point). Používajte celočíselné drobné jednotky (minor units) alebo presné desatinné miesta, explicitnú menu a deterministické pravidlo zaokrúhľovania pre rozdelenia. Ak rozdelíte 100 € medzi predajcov a poplatky bez jasného pravidla, zatúlaný cent vám rozbije rovnováhu.
Dátum uskutočnenia účtovného prípadu vs. dátum zaúčtovania. Dátum, kedy kupujúci zaplatil, kedy predajca zarobil, kedy banka zúčtovala platbu a kedy bol záznam zaúčtovaný, sú rôzne dátumy. Ich zlievanie robí vykazovanie období a daňové načasovanie nespľahlivým.
Viacmenovosť. Strana má dať a dal by sa mali vyrovnať v rámci danej meny. Konverzia si vyžaduje explicitnú udalosť kurzového rozdielu s účtami pre poplatok, zaokrúhľovanie a akékoľvek kurzové zisky alebo straty. Samotné akceptovanie poľa currency nerobí z účtovnej knihy devízový nástroj.
Čo za vás API účtovnej knihy neurobí
Neurčí vašu účtovnú osnovu. Stále musíte sami určiť, či vystupujete ako komitent alebo sprostredkovateľ, kedy je provízia zarobená, ktorá strana znáša poplatky platobnej brány, ako vrátenie peňazí ovplyvňuje províziu a ako sa počíta a vykazuje DPH. Odporúčanie spoločnosti Nordlet hovorí: najskôr si mapujte peňažné toky, navrhnite účtovnú osnovu, nechajte ju skontrolovať účtovníkom a až potom implementujte jeden celý tok od objednávky cez výplatu a odsúhlasovanie, než pristúpite k škálovaniu.
Nevyrieši daňové otázky. DPH závisí od lokality kupujúceho a predajcu, typu produktu, registračného statusu a pravidiel pre považovaného dodávateľa (deemed-supplier rules); sprievodca DPH v EÚ stanovuje, čo systém dokáže odvodiť a čo označuje pre ľudskú kontrolu. Pokrytie DPH v Nordlet je zamerané na EÚ a EHP, takže sa nevzťahuje na americkú daň z obratu (sales tax) ani na latinskoamerickú elektronickú fakturáciu. Nevyrieši ani prevádzkovú nejednoznačnosť - či uplynula lehota na vrátenie tovaru, či by mala byť výplata zablokovaná, či je platba podvodná. Toto sú vaše rozhodnutia. Účtovná kniha iba zaznamenáva ich finančný výsledok.
Kam zapadá Nordlet
Nordlet je účtovné API vytvorené pre platformy a preoviská, ktoré ponúka nemennú podvojnú účtovnú knihu, výplaty, správu DPH v EÚ, koncové body REST, typované SDK a webhooky dostupné cez jedno rozhranie. Jeho charakteristickou črtou je integrované účtovníctvo priamo vo vašom produkte namiesto riešenia cez platobnú bránu tretej strany. V čase písania tohto článku je produkt vo fáze skorého prístupu (early access) so sandboxom pre partnerské firmy, takže ho vnímajte ako silného zástupcu danej kategórie a pred vlastným nasadením do produkcie dôkladne vyhodnoťte jeho produkčnú zrelosť, dostupnosť (uptime) a pokrytie legislatívnych požiadaviek pre váš konkrétny prípad.
Pre vývojárov preovísk a platforiem je užitočným mentálnym modelom rozdelenie medzi pohybom peňazí a finančnou pravdou. Vaša platobná brána presúva peniaze. API podvojného účtovníctva zaznamenáva, kto má na čo nárok, čo ste zarobili, aké dane a rezervy spravujete a či sa vonkajší svet zhoduje s vašimi knihami.
FAQ
Je API podvojného účtovníctva to isté ako platobná brána?
Nie. Platobná brána autorizuje, inkasuje, zúčtováva a niekedy aj vypláca finančné prostriedky. API účtovnej knihy zaznamenáva účtovné dôsledky týchto udalostí. Väčšina preovísk používa oboje - bránu ako Stripe alebo Adyen na pohyb peňazí a účtovnú knihu pre samotné účtovníctvo.
Môžem použiť panel platobnej brány ako hlavnú účtovnú knihu?
Môžete to skúsiť, ale auditom to nakoniec neprejde. Reporty platobnej brány ukazujú poplatky, prevody a zúčtovania, ale zvyčajne nezobrazujú vaše kompletné záväzky voči predajcom, daňové povinnosti, iné než bránové výdaje alebo účtovné úpravy. Berte ich len ako vstup pre odsúhlasovanie.
Znamená vyrovnaná účtovná kniha, že moje účtovníctvo je správne?
Iba to, že vaše záznamy spĺňajú pravidlo má dať a dal. Dokonale vyrovnaná transakcia môže byť stále zaúčtovaná na nesprávny účet, nesprávnemu predajcovi alebo s nesprávnym daňovým zaobchádzaním. Rovnováha je nutná, ale nie postačujúca podmienka. Odsúhlasovanie je to, čo zachytí zvyšok.
Ak je účtovná kniha nemenná, ako opravím chyby?
Zaznamenáte stornovací záznam a následne opravený záznam. Pôvodný záznam zostane viditeľný, čo je celkovo podstata tohto prístupu. Nemennlivosť chráni auditnú stopu, nezväzuje vám ruky pri chybách.
Zabezpečí mi účtovné API automatický súlad s predpismi?
Nie. Vynucuje účtovnú štruktúru a vytvára použiteľné záznamy. Súlad s právnymi predpismi stále závisí od vašej jurisdikcie, zmluvnej úlohy, daňového zaobchádzania, platobných predpisov, procesov KYC a AML a vykazovacích povinností.