Kétszámlás könyvelési (double-entry ledger) API-k piactéri könyveléshez

A legtöbb piactér ugyanúgy veszi észre, hogy könyvelési problémája van: megérkezik az új pénzügyi munkatárs, megnyitja a kifizetési táblázatot, és felteszi a kérdést, hogy valójában ki tartja nyilván az eladók felé fennálló tartozást attól a pillanattól kezdve, hogy a vevő fizet, egészen addig, amíg a pénz elhagyja a platform számláját. A fejlesztőcsapat rámutat egy transactions (tranzakciók) táblára, mire a pénzügyi kolléga elmagyarázza, hogy az események listája nem egyenlő a főkönyvvel. Ezt a szakadékot – az eseményadatok és a valós könyvelés közötti űrt – hivatott áthidalni a kétszámlás könyvelési (double-entry ledger) API.

Ez egy olyan technikai kérdés, amelynek komoly szabályozási tétje van. A piacterek más pénzét kezelik, joghatóságokon átívelően számítanak fel áfát, és az eladók nevében állítanak ki számlákat. Házon belül összerakott tranzakciós táblákkal ezt addig lehet csinálni, amíg egy auditor, egy adóhatóság vagy egy komolyabb befektető nem követel hiteles bizonyítékot.

Valójában mi az a kétszámlás könyvelési API?

A kétszámlás könyvelési API egy HTTP-n keresztül elérhető, programozható könyvelési motor. A platform által rögzített minden egyes pénzügyi eseményt egy egyensúlyban lévő könyvelési tételként ír le: legalább egy tartozik (debit) és egy követel (credit) sor szerepel benne, amelyek összege megegyezik, és a számlatükör (chart of accounts) elnevezett számláira könyvelődnek. Az API rögzítéskor érvényesíti ezt az egyensúlyt, és úgy tárolja a tételeket, hogy azokat később ne lehessen észrevétlenül módosítani.

A „kettős könyvvitel” része az a négyszáz éves számviteli szabály, amely szerint minden tranzakció legalább két számlát érint. Az „API” rész azt jelenti, hogy a hívó fél az Ön terméke, nem pedig egy hús-vér könyvelő. A „megváltoztathatatlan” (immutable) pedig azt takarja, hogy a helyesbítések sztornírozó tételekkel történnek, nem pedig a múltbeli adatok átírásával. E három tulajdonság együtt teszi a kapott könyveket auditálhatóvá ahelyett, hogy csupán rendezettek lennének.

Egy hasznos munkadefiníció:

A kétszámlás könyvelési API fogadja az alkalmazástól érkező pénzügyi eseményeket, mindegyiket egy kiegyensúlyozott könyvelési tétellé alakítja egy meghatározott számlatükör alapján, megváltoztathatatlanul tárolja ezeket a tételeket, valamint kiszámítható végpontokon keresztül teszi elérhetővé a főkönyvet, a próbamerleget (trial balance) és a pénzügyi jelentéseket.

A Nordlet pontosan erre az elgondolásra épül: valós főkönyv API-ként, ahol a könyvelés, az áfalogika, a számlázás és a megbízási egyeztetés (reconciliation) egyaránt elérhető ugyanabból a végpontcsaládból, amellyel a terméke már eddig is kommunikált.

Miért van erre kifejezetten szükségük a piactereknek?

Egyetlen kereskedőt kiszolgáló SaaS-szolgáltató gyakran megússza annyival, hogy naponta egyszer szinkronizál egy általános könyvelési szoftverrel. A piacterek ezt nem tehetik meg, mégpedig három okból.

Először is, ők ülnek a pénz útjának közepén. A vevő fizet a platformnak, a platform őrzi az összeget, majd a díjakkal csökkentve kifizeti az eladókat. E mozgások mindegyike különálló számviteli esemény, amely különböző számlákat érint: készpénz/pénzeszközök, eladói kötelezettségek, platformbevételek, fizetendő áfa, visszatérítési céltartalékok. Egy payments (fizetések) tábla, amely egy status (állapot) oszlopot tartalmaz, ezt nem tudja leképezni.

Másodszor, adóhatárokon átívelően működnek. Egy olyan uniós piactérnek, amelynek eladói Litvániában, Németországban és Lengyelországban, vevői pedig az egész közösség területén találhatók, tranzakciónként kell alkalmaznia a helyes áfabesorolást, ellenőriznie kell az eladók adószámát a VIES rendszerében, és olyan jelentéseket kell készítenie, amelyek megfelelnek az egyes helyi hatóságok előírásainak. Ha ezt az alkalmazáskódban próbálják helyesen beállítani, majd egy külön könyvelési rendszerrel egyeztetni, az a pont, ahol a legtöbb piactér csendben elbukik.

Harmadszor, a tranzakciószám túl nagy a kézi könyveléshez. Egy olyan platform, amely havi tízezer rendelést bonyolít le, tízezrével termeli a könyvelési tételeket. Ezt elejétől a végéig automatizálni kell, különben a pénzügyi csapat a növekedés szűk keresztmetszetévé válik.

Hogyan működik az API lépésről lépésre?

A mechanika kevésbé misztikus, mint amilyennek hangzik. Egy piactéri rendelés tipikus folyamata a következő:

1. A platform pénzügyi eseményt bocsát ki. A vevő befejezi a fizetést. A háttérrendszere hívja a könyvelési API-t olyan adatokkal, mint: rendelés azonosítója, vevő, eladó, bruttó összeg, áfakulcs, platformjutalék, pénznem és egy idempotencia-kulcs (idempotency key).

2. A könyvelőmotor összeállítja a tételt. Az API lefordítja ezt az eseményt tartozik és követel tételekre. Egy egyszerű piactéri eladás esetén ez azt jelentheti, hogy megterhelnek egy úton lévő pénzeszközök számlát, jóváírják a nettó összeget az eladói kötelezettségek számlán, a jutalékot a platformbevételi számlán, az adóalapot pedig a fizetendő áfa számlán. Minden egyensúlyban van, és atomi módon könyvelődik.

3. A tétel megváltoztathatatlanul rögzítésre kerül. A könyvelést követően a tétel kap egy azonosítót és egy időbélyegzőt, és nem módosítható. Ha valami hiba csúszott be, sztornírozó tételt, majd egy helyesbített tételt kell feladni. Az auditálhatósági nyomvonal (audit trail) itt a lényeg.

4. A downstream jelentések valós időben frissülnek. A próbamerleg, az eladói kötelezettségek egyenlege, az áfa-összesítők és az eredménykimutatás azonnal tükrözik az új tételt. Nincs éjszakai futtatás, nincs exportálás, és nincs olyan egyeztetési időszak, amikor az adatok még „lebegnek”.

5. Webhookok értesítik a rendszert. Az olyan események, mint a sale_invoice.paid (eladási számla kifizetve) vagy a bank_transaction.matched (banki tranzakció párosítva) webhook üzenetet küldenek a végpontjainkra, így a terméke lekérdezések nélkül is reagálni tud. Az idempotencia-kulcsokkal együtt ez azt jelenti, hogy az újrapróbálkozások biztonságosak, és hálózati hiba esetén sem kúsznak be duplikációk.

A legfontosabb tervezési szempont: a könyvelés jelenti a valóság forrását (source of truth) abban a tekintetben, hogy mi történt pénzügyileg. Az alkalmazás adatbázisa a termék állapotának a forrása. A két rendszer azért van szinkronban, mert a főkönyvet az alkalmazás eseményei alapján írják, nem pedig fordítva.

A számlatükör kialakítása kulcsfontosságú

A piactér könyvelési rendszerének felépítése során a szellemi munka nagy része a számlatükör kialakítására irányul. Ez azon elnevezett gyűjtőszámlák listája, amelyekre a tartozik és követel tételek érkeznek: bankonkénti pénzeszközszámlák, eladói kötelezettségek számlái (gyakran eladónként egy, vagy egy összesítő számla alszámlákkal), kategóriák szerinti platformbevételek, országonkénti fizetendő áfák, visszatérítési céltartalékok, terhelés-visszaterhelési (chargeback) céltartalékok és így tovább.

Néhány minta, ami folyamatosan visszaköszön a piactereknél:

• Az eladók pénze kötelezettség, nem bevétel. Az eladók nevében őrzött pénz kötelezettségnek számít. Bevételként kezelni, majd a kifizetést később költségként elszámolni az a klasszikus hiba, amely átvilágításkor (due diligence) azonnal kibukik.
• Az áfa országonként külön kötelezettség. Ha több uniós joghatóságban működik, akkor országonként külön fizetendő áfa számlákra van szüksége, hogy a bevallások tisztán leképezhetők legyenek.
• A díjakat abban a pillanatban kell modellezni, amikor megszerzik őket, nem pedig a kifizetésükkor. Az érdemi (teljesítés alapú) elszámolás itt elengedhetetlen.
• A visszatérítéseknek, chargebackeknek és vitás ügyeknek saját számlákra van szükségük, hogy az eredménykimutatás a valóságot tükrözze, ne pedig a pozitív és negatív eladások kaotikus keverékét.

Egy jó könyvelési API lehetővé teszi, hogy ezt a struktúrát egyszer definiálja, majd magabiztosan könyveljen rá ahelyett, hogy újra feltalálná a számviteli logikát a fizetési (checkout) kódban.

Megváltoztathatatlanság, időszakzárás és az auditorok szempontjai

A megváltoztathatatlanság (immutability) elsőre adatbázis-technikai részletnek tűnhet. Valójában ez a különbség olyan könyvek között, amelyeket egy auditor aláír, és olyanok között, amelyeket nem.

Ha egy piactér csendben módosíthatja az előző negyedév tételeit, akkor az előző negyedév adatai könyvelési értelemben véve megismerhetetlenek. Egy megváltoztathatatlan főkönyv érvényesíti azt a szabályt, hogy a múlt az múlt. A helyesbítések helyesbítésként látszódnak. Az időszakzárás (period locking) ezt kiterjeszti: ha egy hónapot lezártak, oda új tétel vagy módosítás nem érkezhet kifejezett újranyitási művelet nélkül, amit ráadásul naplóznak is.

Azok számára a platformok számára, amelyek a jövőben tőkét kívánnak bevonni, el akarják magukat adni, vagy adóvizsgálattal néznek szembe, ez nem egy „jó, ha van” extra. Ez az a tényező, ami védhetővé teszi a könyveket. A Nordlet főkönyve alapértelmezés szerint erre épül, a megváltoztathatatlan kettős könyvelési struktúrával és a beépített időszakzárással, nem pedig utólag ráaggatott kiegészítésekkel.

Uniós áfa: ami felemészti a fejlesztési időt

Az áfa az a terület, ahol a legtöbb piactéri könyvelési projekt csúszik. A szabályok nem merülnek ki annyiban, hogy „alkalmazzunk egy százalékot”. Attól függnek, hogy hol van a vevő, hol van az eladó, mit adnak el, az eladó rendelkezik-e áfa-regisztrációval, a piactér a 2021-es e-kereskedelmi szabályok értelmében vélelmezett eladónak (deemed supplier) minősül-e, és melyik helyi adatszolgáltatási rezsim az irányadó.

Egy EU-s piacra szánt komoly könyvelési API legalább az alábbiakat kezeli:

• VIES ellenőrzés az eladói és vevői adószámokhoz, ideális esetben a tranzakcióhoz rögzített és gyorsítótárazott (cached) eredményekkel.
• Országonkénti áfakulcs-logika, beleértve a kedvezményes kulcsokat és a mentesítéseket.
• i.SAF regiszter generálás a litván adóbevallásokhoz, valamint megfelelő strukturált kimenetek, ha más tagállamok ezt írják elő.
• Peppol BIS 3.0 e-számlázás azokhoz a joghatóságokhoz, amelyek kötelezővé teszik az elektronikus számlázást.
• OSS/IOSS kezelés a határokon átnyúló B2C értékesítésekhez.

Ha ezt alkalmazáskódban, országonként próbálják lefejleszteni, az egy teljes fejlesztőcsapat munkáját köti le, és soha nincs teljesen kész, mert a szabályok folyamatosan változnak. Átvinni ezt a könyvelési rétegbe a pragmatikus döntés.

Az egyeztetés (reconciliation), ahol az időszafizetés látszik

Ha a főkönyv egyszer a valóság forrása, a banki egyeztetés megszűnik havi gyötrelem lenni. Megérkeznek a bankkivonatok, a főkönyv már tudja, mi kellene ott legyen, a párosítás pedig nagyrészt automatikus.

Ennek a valósághű változata nem a „nulla kézi munka”, hanem az, hogy „a kivételek maguktól felszínre kerülnek”. A tisztán párosuló tranzakciók kilencven százalékához egykattintásos egyeztetési folyamat tartozik, plusz a tíz százalékot kitevő sorok listája, amelyek emberi döntést igényelnek – nagyjából ezt nyújtja egy jól megtervezett megbízási egyeztetési API. Az okos fizetéspárosítás kezeli a részfizetéseket, a túlfizetéseket és azokat a tranzakciókat, amelyek több számlát fednek le anélkül, hogy egy embernek kellene külön szabályokat írnia az egyes esetekre.

A kimenő oldalon a SEPA-export (pain.001 formátum) zárja be a kört a beszállítói és eladói kifizetéseknél. Ön jóváhagyja a kifizetéseket a termékében, a könyvelés előállítja a SEPA-fájlt, a bank feldolgozza, az eredményül kapott mozgást pedig a rendszer automatikusan visszaegyezteti.

Fejlesztés házi erővel vs. vásárlás vs. beágyazás

A piactéri csapatok általában három út közül választanak. Így viszonyulnak egymáshoz a fontos szempontok mentén:

Megközelítés	Gyártási idő	Auditálhatóság	Uniós áfakezelés	Beilleszthető a termékbe?
Saját főkönyv fejlesztése	12-24+ hónap	Teljes mértékben a csapattól függ	Önnek kell lefejleszteni, országonként	Igen
Szinkronizálás Xero/QuickBooks rendszerrel	Hetek	Jó a könyvelési oldalon, gyenge a piactéri folyamatokban	Részleges, kiegészítők szükségesek	Nem, egy külön eszközben fut
Könyvelési API beágyazása (pl. Nordlet)	Hetek	Beépítve a megváltoztathatatlan főkönyv és az időszakzárás révén	Beépítve az EU-ra, VIES és i.SAF támogatással	Igen, API-kon és SDK-kon keresztül

A saját fejlesztés akkor védhető, ha a könyvelés magának a terméknek a lényege. Mindenki más számára a matematika ritkán jön ki. A hagyományos könyvelési szoftverrel való szinkronizálás működik az egyszemélyes vállalkozásoknál, de összeroppan a piactéri folyamatok súlya alatt: a felosztott fizetések, az eladói alszámlák, az országonkénti áfák és a platform, mint vélelmezett eladó forgatókönyvei nem képezhetők le tisztán egyetlen cég könyvelésére tervezett eszközökben.

Az API-központú könyvelés beágyazása az az irány, ami felé a modern platformok konvergálnak. A könyvek a termék élményén belül élnek, az eladók saját pénzügyeiket látják az Ön felhasználói felületén (UI), és a megfeleléssel járó nehéz terheket az infrastruktúra réteg kezeli.

Mit kell keresni egy könyvelési API kiértékelésekor?

Egy rövid ellenőrzőlista, amelyet érdemes nyitva tartani a szállítókkal folytatott megbeszélések során:

• Megváltoztathatatlan kettős könyvelési tárolás sztornírozó tételes korrekciókkal, nem pedig szerkeszthető sorokkal.
• Időszakzárás naplózott újranyitási műveletekkel.
• Idempotencia-kulcsok minden írási végponton.
• Webhookok azokhoz az eseményekre, amelyekre a terméknek reagálnia kell, ne csak egy lekérdező (polling) API.
• Típusos SDK-k azokon a nyelveken, amelyeket a csapata ténylegesen használ.
• Országonkénti áfalogika, beleértve a VIES-t, az i.SAF-ot vagy ezek ekvivalenseit, valamint az OSS/IOSS-t.
• Több vállalkozást (multi-company) támogató architektúra, ha több jogi egységgel működik vagy tervez működni.
• Szerepkör-alapú hozzáférés, amely kellően részletes a fejlesztők, könyvelők és megtekintők szétválasztásához.
• Jelentésexportok XLSX, PDF és JSON formátumban, webhook értesítésekkel, amikor a nagyobb jelentések elkészültek.
• Homokozó (sandbox) környezet, amely a termelési (production) viselkedést tükrözi, nem pedig egy lecsupaszított demó.

Ha egy szolgáltató technikai hívás során nem tudja bemutatni az első hármat, a többi már nem is számít.

Mit tennék először?

Ha egy piactér a semmiből kezdi ezt a munkát, a következő sorrend kíméli meg a legtöbb fejfájást:

1. Írás előtt vázolják fel a valós pénzfolyamatokat egy táblán. Ki tartozik kinek, milyen pillanatban, milyen pénznemben, milyen áfakezeléssel.
2. Ebből a térképből tervezzék meg a számlatükröt. Eladói kötelezettségek, platformbevételek, országonkénti fizetendő áfa, céltartalékok. Ellenőriztessék egy könyvelővel, mielőtt élesbe menne.
3. Válasszák ki a könyvelési réteget. Fejlesztés, szinkronizálás vagy beágyazás. Legyenek őszinték abban, hogy a csapatuk mit tud ténylegesen leszállítani és karbantartani.
4. Valósítsanak meg egy folyamatot elejétől a végéig: rendeléstől a számlán és a kifizetésen át egészen az egyeztetésig. Bizonyítsák be, hogy egyensúlyban van. Utána jöhet a skálázás.
5. Kapcsolják be az időszakzárat, amint az első hónap tisztán lezárult. A fegyelem meghozza a gyümölcsét.

Azok a csapatok csinálják ezt jól, amelyek a főkönyvet alapvető infrastrukturális elemként kezelik, nem pedig utólagos jelentéskészítési melléktermékként. Ez a szemléletváltás, és ez az, amitől az auditorral, a befektetővel vagy az adóhatósággal folytatott pénzügyi beszélgetés rövid lesz a hosszú helyett.

FAQ

Ugyanaz a kétszámlás könyvelési API, mint egy számviteli integráció?

Nem. Az integráció adatok szinkronizálását végzi a termékből egy külső számviteli eszközbe, általában késleltetéssel. A könyvelési API maga a könyvelési rendszer, amelybe közvetlenül, valós időben írnak. A különbség azért fontos, mert az integrációk a széleken veszítenek a pontosságból: részfizetések, multi-currency, piactéri felosztások. A könyvelési API ezeket natív módon rögzíti.

Nem használhatnánk egyszerűen a Stripe vagy az Adyen jelentéseit?

A fizetési feldolgozó jelentései azt mutatják meg, hogy mi ment át a feldolgozón. Azok nem kétszámlás könyvek. Nem tudnak a még ki nem fizetett eladói kötelezettségekről, az országokon átívelő áfakötelezettségekről vagy a nem a fizetési feldolgozón keresztül merülő kiadásokról. Ezek egyetlen bemeneti forrást jelentenek a főkönyvhöz, nem pedig annak helyettesítői.

Mennyire megváltoztathatatlan a megváltoztathatatlan a gyakorlatban?

A tételeket nem lehet módosítani. A korrekciók új tételek, amelyek az eredetire hivatkoznak. Ez tervezési döntés, nem pedig technológiai korlát. Bármely kompetens könyvelőmotor betartatja. Azért fontos ezt figyelni, mert a „megszerkesztettük, hogy egyezzen a bankkal” pont az a minta, amitől a könyvek hiteltelenné válnak.

Mi a helyzet a nem uniós piacterekkel?

A kettős könyvvitel mechanikája univerzális. Az adózási logika nem. Az uniós áfára hangolt könyvelési API jól kezeli az EU-s túlsúlyú műveleteket, és támogatni tudja a nem uniós tranzakciókat is, de ha az Ön elsődleges piaca az amerikai forgalmi adó (sales tax) vagy a latin-amerikai e-számlázási rezsimek, elköteleződés előtt ellenőrizze a specifikus megfelelést.

Mennyi ideig tart valójában a megvalósítás?

Egy tiszta eseménymodellel rendelkező piactér számára a könyvelési API beágyazása egyetlen teljes folyamat végrehajtásáig jellemzően néhány hét mérnöki munkát igényel. Egy örökölt rendszerből történő teljes migráció, beleértve a történelmi adatokat is, hosszabb ideig tart. A változó tényező szinte mindig a meglévő adatok állapota, nem maga az API.