Mi az a kettős könyvviteli főkönyvi API piacterek számára?

Egy piactér az orders táblája alapján teljesen rendben lévőnek tűnhet, mégis tévedhet a saját pénzügyi helyzetét illetően. A megrendelésnél az szerepel, hogy „fizetve”. Az eladói vezérlőpult mutat egy egyenleget. Ám semmi sem bizonyítja abban a táblázatban, hogy mennyi készpénzt tart kézben a platform, mennyirel tartozik az egyes eladóknak, a kifizetés mekkora része származik jutalékbevételből, vagy mennyi az áfafizetési kötelezettség. A kettős könyvviteli főkönyvi API (double-entry ledger API) pontosan arra való, hogy ezeket a pénzügyi következményeket helyesen, egyenként egyensúlyban lévő tranzakciókként rögzítse.

Egyszerűen fogalmazva: a kettős könyvviteli főkönyvi API egy programozható számviteli rendszer. Az alkalmazás elküld neki egy pénzügyi eseményt – például egy inkasszált fizetést vagy egy jóváhagyott kifizetést –, a főkönyv pedig ezt az eseményt elszámolásként (journal) rögzíti, egyenlő tartozik (debit) és követel (credit) tételekkel a megnevezett számlákon. Ez a rendszer nem mozgat pénzt, hanem rögzíti a valóságot a máshol megmozgatott pénzről.

Mit jelent itt a „kettős könyvviteli főkönyv”?

A főkönyv a számlák változásainak nyilvántartása, nem pedig egy olyan tábla, amely csak a legfrissebb egyenleget tartalmazza. A működő főkönyv három összefüggő elemből áll:

• Számla (Account): egy megnevezett pénzügyi pozíció, mint például a fizetésforgalmi szolgáltatóval szembeni követelés, az eladóknak járó összegek (seller payable), a jutalékbevétel vagy a fizetendő áfa.
• Tranzakció (journal): egyetlen atomi pénzügyi esemény, amely több egyensúlyban lévő tételsort tartalmaz.
• Tétel / könyvelési sor (posting/entry): egyetlen tartozik vagy követel sor az adott tranzakción belül.

Az az invariáns szabály, amely az egészet összetartja, roppant egyszerű: a tartozik és a követel oldali összegeknek minden egyes tranzakcióban és minden pénznemben meg kell egyezniük. A főkönyvi API-k általában elutasítják az egyensúlyhiányos rögzítési kísérletet, mielőtt az egyáltalán eljutna a tárolóba. A Modern Treasury dokumentációja a főkönyvi tranzakciót úgy határozza meg, mint ami két vagy több számlát érint legalább egy-egy azonos összegű tartozik és követel tétellel, és a könyvelt tranzakciót módosíthatatlannak (immutable) tekinti.

A kettős könyvvitel nem jelenti azt, hogy a sorok száma pontosan kettő lehet. Egyetlen piactéri eladás gyakran egy tartozik és több követel tételt igényel. Ezt szokták a legtöbbször félreérteni.

Miért van a piactereknek szükségük főkönyvre a fizetési táblák helyett?

Egy piactér egyszerre több pénzügyi kapcsolatot kezel. A vevő fizet. A szolgáltató elszámol. A platform átmenetileg birtokolhatja az alapokat. Az eladó megszerzi a részét. A platform megtartja a jutalékot. Az adó fizetendővé válik. Előfordulhat, hogy letétet (reserve) tartanak vissza. Később egy kifizetés elmozgatja a pénzt, a visszatérítések vagy a terhelésvisszafordítások (chargeback) pedig ezek egy részét érvénytelenítik.

Egy payments tábla meg tudja mondani egy rendelés kereskedelmi státuszát. Azt azonban nem tudja megbízhatóan megmutatni, hogy:

• mekkora a fizetésforgalmi szolgáltatóval szembeni követelés vagy készpénzállomány,
• mennyi pénzzel tartoznak az egyes eladóknak,
• mekkora bevétel illeti meg a platformot,
• mennyi áfa fizetendő, és melyik országban,
• mekkora összeget tartanak vissza visszatérítésekre vagy vitákra,
• a kifizetés csökkentette-e a helyes eladói kötelezettséget,
• a szolgáltatói elszámolások egyeznek-e a platform várakozásaival.

A Nordlet kettős könyvviteli főkönyvi API-król szóló útmutatója a piactéri számvitelhez világosan meghúzza a határt: az alkalmazástáblák a termék állapotát írják le, míg a főkönyv ezen állapota pénzügyi következményeit rögzíti. Azt is érdemes újra megjegyezni, hogy a fizetési szolgáltatók jelentései az egyeztetés bemeneti adatai, nem pedig teljes körű kettős könyvviteli könyvek.

Egy levezetett piactéri eladás

Tegyük fel, hogy a vevő fizet 100 eurót, az eladót 85 euró illeti meg, a platform jutaléka pedig 15 euró. Az áttekinthetőség kedvéért tekintsünk el az áfától és a szolgáltatói díjaktól.

Számla	Tartozik	Követel	Indoklás
Fizetésforgalmi szolgáltatói követelés	100 €		A szolgáltató tartozik a platformnak a behajtott fizetéssel
Eladói kötelezettség		85 €	A platform tartozik az eladónak
Jutalékbevétel		15 €	A platform megszerezte a jutalékát
Összesen	100 €	100 €	Egyensúlyban

A fontos besorolás itt az, hogy az eladónak fizetendő 85 euró kötelezettség, nem pedig platformbevétel. Az IFRS elvi keretrendszere szerint a kötelezettség egy gazdasági erőforrás átadására vonatkozó jelenlegi kötelezettség. Egy piactér nem könyvelheti el az eladó teljes eladási bevételét saját jövedelmeként pusztán azért, mert a vevőn keresztül fizetett. Az, hogy ügynökként, principal (megbízónak minősülő) félként vagy vélelmezett szállítóként van jelen, megváltoztatja a kezelést, de a főkönyv mechanizmusa ugyanaz marad.

Amikor az eladó jogosultválik a kifizetésre, nem keletkezik új bevétel. Ekkor a kötelezettséget rendezzük:

Számla	Tartozik	Követel
Eladói kötelezettség	85 €
Banki vagy kifizetési elszámolási számla		85 €
Összesen	85 €	85 €

Ha a szolgáltató az elszámolás előtt 3 euró díjat von le, a pénzmozgás egy háromsoros könyvelési tétellé válik: 97 euró a banki készpénzbe, 3 euró a feldolgozási ráfordításba, és 100 euró ki a szolgáltatói követelésből. A pozíció minden változásának van forrása és célállomása.

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

1. Az alkalmazás észleli az üzleti eseményt. Fizetés érkezik, egy rendelést teljesítenek, kifizetést hagynak jóvá, visszatérítést bocsátanak ki, vitás ügy (chargeback) indul, vagy elszámolás érkezik. Az adatbázis továbbra is a műveleti állapotot kezeli, a főkönyv pedig rögzíti a pénzügyi hatást.

2. Strukturált kérést küld. Ez általában tartalmazza az esemény típusát, az összeget és a pénznemet, a rendelés vagy a fizetés azonosítóját, a vevő és az eladó azonosítóit, a jutalékot, az adóadatokat, az érintett számlákat, a teljesítési és könyvelési dátumokat, egy idempotencia-kulcsot, valamint a szolgáltatói és termékrekordokra mutató metaadatokat. A Nordlet nyilvános API-példája egy eladói azonosítóval, eladási típussal, összeggel, pénznemmel, valamint áfakóddal és -kulccsal ellátott elméleti eladási kérelmet mutat be.

3. Az API ellenőrzést végez. Ellenőrzi, hogy a tartozik és követel oldalak egyensúlyban vannak-e, a számlák léteznek-e és könyvelhetők-e, a pénznem támogatott-e, az összeg a kisebb egységek (minor unit) pontos kezelésével szerepel-e, az idempotencia-kulcsot nem használták-e fel újra eltérő eredménnyel, az időszak nyitva van-e, és a szükséges metaadatok rendelkezésre állnak-e. Egy sikertelen ellenőrzés nem hagy maga után hiányos tételt.

4. Atomatikusan könyvel. A teljes tranzakció egységként íródik be. Soha nem fordulhat elő, hogy a tartozik tételt sikerül rögzíteni, míg a hozzá tartozó követel tétel meghiúsul. Egy piactér esetében egy részleges szétválás olyan látszólagos eladói egyenleget hozhatna létre, amelyhez nem tartozik készpénz, vagy jutalékot könyvelne el az eladói kötelezettség nélkül.

5. Az egyenlegek és jelentések a főkönyvből származnak. A könyvelést követően leolvashatók a számlaegyenlegek, az eladók függőben lévő és elérhető egyenlegei, a próbamerleg, a főkönyvi mozgások, az áfa-összesítők és a múltbeli fordulónapi történetek. Az eladói egyenleget a könyvelésekből kell tudni újjáépíteni, nem pedig egy módosítható mezőben bízni.

6. A webhookok értesítik a terméket. Az olyan események, mint a sale_invoice.paid, a könyvelt tranzakció, az elérhető kifizetés vagy egyeztetési kivétel, továbbításra kerülnek. Ezeket idompotens módon kell feldolgozni. A webhook egy értesítés, nem pedig felhatalmazás a pénzügyi esemény második alkalommal történő alkalmazására. Az API-konvenciók részletesen lefedik a hatásköröket, az idempotencia-kulcsokat, a hibaformátumokat és a webhookok aláírását.

Az eladói egyenleg nem egyetlen szám

A legtöbb piactér azért kerül bajba, mert az eladói egyenleget egyetlen számként kezeli. A pénznek különböző állapotokban kell léteznie:

Állapot	Jelentés
Függőben (Pending)	Az eladó jogosult lehet rá, de a felszabadítás feltételei nem teljesültek
Elérhető (Available)	Kifizetésre alkalmas
Visszatartott (Reserved)	Visszatérítések, elállások vagy viták miatt visszatartva
Kifizetve (Paid out)	A kötelezettség átutalással rendezve
Negatív	A visszatérítések, terhelésvisszafordítások vagy díjak meghaladják az elérhető összeget

A fizetési szolgáltatók modelljei ezt tükrözik. A Stripe különálló terhelési és átutalási folyamatai lehetővé teszik, hogy a platform megterhelje a saját számláját, majd részleteket utaljon át a kapcsolódó számlákra úgy, hogy a díjak, visszatérítések és terhelésvisszafordítások a platform egyenlegén landoljanak. Az Adyen piactéri modellje megkülönbözteti a kifizetésig a pénzeszközöket tartó felhasználói egyenlegszámlákat és a terhelésvisszafordításokból vagy vitákból eredő negatív egyenlegeket elviselni képes felelősségi egyenlegszámlákat. Ezek hasznos bemenetek a főkönyv számára, de nem alkotják a teljes számviteli modellt.

A kifizetések és az eladói bevételek eltérő időben történnek

Egy eladó kereshet pénzt hétfőn, és megkaphatja a kifizetést a következő hétfőn. Ezen időpontok között a rendelés teljesül, letétet tartanak vissza, kifizetési köteg épül fel, egy szolgáltató nettó módon elszámol, és megérkezik a banki átutalás. A főkönyvnek minden egyes szakaszt meg kell őriznie ahelyett, hogy a rendelést felülírná egy végleges „fizetve” státusszal. Ez teszi lehetővé az időbeli eltérések magyarázatát a rendelési tevékenység, az eladói jogosultság, az elszámolás, a kifizetés indítása és a banki jóváírás között.

Visszatérítések és terhelésvisszafordítások: helyesbítés, nem átírás

A visszatérítések és a terhelésvisszafordítások az eredeti fizetéshez kapcsolódó új események. Egy módosíthatatlan (immutable) főkönyvben a helyesbítést egy sztornírozó tétellel, majd egy helyesbített tétellel végezzük el, így az eredeti tétel látható marad az audit számára. A Modern Treasury a könyvelt tranzakciókat módosíthatatlanként kezeli, és támogatja az idempotencia-kulcsokat, hogy megakadályozza a duplikált objektumok létrejöttét az újrapróbálkozások során.

A visszatérítés általában csökkenti a készpénzt vagy a vevői követelést, sztornírozza az eladói kötelezettséget, a szabályzattól függően csökkentheti a jutalék egy részét, kiigazítja az adót, és felemészthet egy visszatérítési tartalékot. A terhelésvisszafordítás csökkenti a készpénzt vagy a szolgáltatói követelést, újra megnyithat az eladó vagy a platform által fizetendő összeget, vitás ráfordítást és szolgáltatói díjat rögzít, valamint egy tartalékszámlán keresztül mozgat pénzeszközöket.

Egyeztetés: a főkönyv összekötése a valós pénzzel

Egy főkönyv lehet belsőleg egyensúlyban, mégis tévedhet a külvilággal kapcsolatban. Az egyeztetés (reconciliation) összehasonlítja a belső nyilvántartásokat a külső bizonyítékokkal: a szolgáltatói elszámolási jelentésekkel, a bankkivonatokkal, a kifizetési fájlokkal, valamint a visszatérítési és vitás jegyzőkönyvekkel.

Egy működőképes ciklus így néz ki:

1. Importálja az elszámolási vagy banki köteget.
2. Párosítsa az egyes sorokat egy rendeléssel, fizetéssel, visszatérítéssel, díjjal, kifizetéssel vagy vitával.
3. Hasonlítsa össze a várt bruttó összeget, a levonásokat, a tartalékokat és a nettó értéket.
4. Könyvelje le a megerősített mozgásokat a főkönyvbe.
5. Küldje a párosítatlan tételeket egy elnevezett átmeneti (suspense) számlára.
6. Vizsgálja meg a kivételeket.
7. Zárja le az időszakot.

A Nordlet egyeztetési anyaga pontosan ezt írja le: elszámolási kötegek importálása, a terhelési és visszatérítési sorok párosítása, valamint a párosítatlan bevételek átmeneti számlára történő irányítása a számla találgatása helyett. Két ellenőrzés számít, és egyik sem helyettesíti a másikat: a kettős könyvviteli ellenőrzés azt vizsgálja, hogy minden könyvelés egyensúlyban van-e, az egyeztetés pedig azt, hogy az megegyezik-e a szolgáltatóval, a bankkal és az üzleti eseménnyel.

Tervezési részletek, amelyek eldöntik a sikerességet

Idempotencia. Kösse a kulcsot egy stabil eseményhez, például a payment_captured:pi_123-hoz. Az újrapróbálkozás az eredeti eredményt adja vissza, nem pedig egy második könyvelési tételt.

Atomicitás. Egy esemény minden sora egyszerre kerül könyvelésre, vagy egy sem.

Módosíthatatlanság (immutability) és sztornózás. A könyvelt előzmények nem szerkeszthetők átlagos frissítésekkel. A javítások kapcsolódó tételeket hoznak létre, amelyek megőrzik az eredeti összeget, dátumot, besorolást, indoklást és készítőt.

Pontos pénzkezelés. Nincs bináris lebegőpontos aritmetika. Használjon egész számú kisebb egységeket vagy pontos tizedeseket, explicit pénznemet, valamint a felosztásokhoz tartozó determinisztikus kerekítési szabályt. Ha 100 eurót oszt fel eladók és díjak között szabály nélkül, egy eltévedt cent felborítja az egyenletet.

Teljesítési és könyvelési dátumok. Az a dátum, amikor a vevő fizetett, amikor az eladó kereste a pénzt, amikor a bank elszámolt, és amikor a tétel könyvelésre került, eltérő napok. Ezek összemosása megbízhatatlanná teszi az időszaki jelentéskészítést és az adózás időzítését.

Többpénznemesség. A tartozik és a követel oldarnak egy adott pénznemen belül kell egyensúlyban lennie. Az átváltáshoz explicit árfolyam-eseményre van szükség a díj, a kerekítés, valamint az esetleges árfolyamnyereség vagy -veszteség számláival. A currency mező elfogadása még nem teszi a főkönyvet valutakezelő motorvá.

Amit a főkönyvi API nem fog megtenni Ön helyett

Nem fogja eldönteni az Ön számlatükrét. Önnek kell meghatároznia, hogy megbízóként (principal) vagy ügynökként jár-e el, mikor érdemli ki a jutalékot, melyik fél viseli a szolgáltatói díjakat, a visszatérítések hogyan érintik a jutalékot, valamint hogyan kell kiszámítani és jelenteni az áfát. A Nordlet saját útmutatása szerint először térképezze fel a pénzmozgásokat, tervezetze meg a számlatükröt, vizsgáltassa meg könyvelővel, majd valósítson meg egy teljes folyamatot a rendeléstől a kifizetésen és az egyeztetésen át, mielőtt skálázna.

Nem oldja meg az adózási kérdéseket. Az áfa a vevő és az eladó tartózkodási helyétől, a terméktípusától, az adóalanyiság státuszától és a vélelmezett szállítói szabályoktól függ; az uniós áfa útmutató bemutatja, mit vezet le a motor, és mit jelöl meg emberi felülvizsgálatra. A Nordlet áfa-lefedettsége az EU-ra és az EGT-re összpontosít, így nem terjed ki az amerikai forgalmi adóra vagy a latin-amerikai e-számlázásra. Emellett nem oldja meg a működési kétértelműségeket sem: hogy letelt-e a visszaküldési ablak, blokkolni kell-e egy kifizetést, vagy csalárd-e a fizetés. Ezek az Ön döntései. A főkönyv csupán rögzíti azok pénzügyi eredményét.

Hova illeszkedik a Nordlet?

A Nordlet egy platformoknak és piactereknek készült számviteli API, amely módosíthatatlan kettős könyvviteli főkönyvet, kifizetéseket, uniós áfa-kezelést, REST-végpontokat, típusos SDK-kat és egyetlen felületen elérhető webhookokat biztosít. Megkülönböztető jellemzője, hogy a számvitelt beágyazza a saját termékbe a harmadik féltől származó fizetési oldalak helyett. A cikk írásakor a termék korai hozzáférésű fázisban van, a tervezőpartnerek számára elérhető sandbox környezettel, ezért tekintse ezt a kategória erős példájának, és mielőtt elkötelezné magát, értékelje ki a saját esetében a gyártási érettséget, az üzemidőt és a joghatósági lefedettséget.

A piactéri és platformfejlesztők számára a hasznos mentális modell a fizetési mozgás és a pénzügyi igazság közötti szétválasztás. A fizetési szolgáltató mozgatja a pénzt. A kettős könyvviteli főkönyvi API pedig rögzíti, hogy kinek mivel tartoznak, mit keresett, milyen adókat és tartalékokat visel, és hogy a külvilág egyezik-e a könyveivel.

FAQ

Ugyanaz a kettős könyvviteli főkönyvi API, mint a fizetési szolgáltató?

Nem. A szolgáltató engedélyez, befogad, elszámol, és néha kifizetéseket teljesít. A főkönyvi API rögzíti ezen események számviteli következményeit. A legtöbb piactér mindkettőt használja: egy olyan szolgáltatót, mint a Stripe vagy az Adyen a pénzmozgáshoz, és egy főkönyvet a könyvekhez.

Használhatom egyszerűen a fizetési szolgáltatóm vezérlőpultját főkönyvként?

Megpróbálhatja, de előbb-utóbb elbukik egy ellenőrzésen. A szolgáltatói jelentések mutatják a terheléseket, díjakat, átutalásokat és elszámolásokat, de általában nem tükrözik a teljes eladói kötelezettséget, az adótartozásokat, a nem a szolgáltatóhoz kötődő ráfordításokat vagy a számviteli kiigazításokat. Tekintse ezt az egyeztetés bemenetének.

Jelenti-e az egyensúlyban lévő főkönyv azt, hogy a könyveim helyesek?

Csak azt, hogy a tételei eleget tesznek a tartozik-követel szabálynak. Egy tökéletesen egyensúlyban lévő tranzakciót még mindig lehet rossz számlára, rossz eladónak vagy helytelen adókezeléssel könyvelni. Az egyensúly szükséges, de nem elégséges feltétel. A többit az egyeztetés szűri ki.

Ha a főkönyv módosíthatatlan, hogyan javíthatom ki a hibákat?

Egy sztornírozó tételt, majd egy helyesbített tételt könyvel le. Az eredeti látható marad, ami az egésznek a lényege. A módosíthatatlanság védi az audit nyomvonalat, de nem zárja be a hibákat.

Automatikusan megfelelőséget biztosít egy számviteli API?

Nem. Ez a rendszer érvényesíti a számviteli struktúrát és használható nyilvántartásokat készít. A jogi megfelelőség továbbra is függ az Ön joghatóságától, szerződéses szerepétől, adókezelésétől, fizetési előírásaitól, a KYC- és AML-folyamataitól, valamint a jelentéstételi kötelezettségeitől.

További olvasnivalók

• Kettős könyvviteli főkönyvi API-k a piactéri számvitelhez
• Defining double-entry ledgers, Formance