Beépített könyvelés: saját fejlesztés vagy vásárlás piacterek számára
Funkciólista, költségmodell megadott feltételekkel, valamint azok a körülmények, amelyek mellett az egyes döntések helytállók.
Idővel minden piactér kiépít egy saját főkönyvet. Az egyetlen kérdés az, hogy ez szándékosan történik-e, ellenőrzési pontokkal ellátott rendszerként, vagy véletlenül, egy olyan balance oszlopként, amelybe három külön szolgáltatás ír, és senki sem bízik benne teljesen.
Ez a cikk arról szól, hogy ezt a döntést tudatosan hozzuk meg. Bemutatja, hogy mit takar a munka a valóságban, hogyan számoljuk ki a költségeket önbecsapás nélkül, és mik azok a konkrét feltételek, amelyek mellett a saját fejlesztés a helyes válasz - mert olykor valóban az.
Mit jelent itt a „beépített könyvelés” (embedded accounting)?
A beépített könyvelés azt jelenti, hogy a nyilvántartások közvetlenül a terméken belül futnak, ahelyett, hogy valaki egy különálló alkalmazást nyitna meg ehhez. A szoftver az események bekövetkeztekor rögzíti a tételeket, a felhasználók azt látják, amit az Ön felülete mutat nekik, és hónap végén senki nem exportál táblázatot egy könyvelőnek.
Egy piactér esetében ez legalább a következőket foglalja magában: beérkezett vevői kifizetések, az eladóknak járó összegek, megszerzett jutalék, fizetésfeldolgozási díjak, az Ön díjaira és az alapul szolgáló termékre vagy szolgáltatásra vonatkozó áfa, visszatérítések, terhelés-visszaterhelések (chargeback), tartalékok, kifizetések, valamint mindezek egyeztetése a banki vagy fizetési szolgáltatói adatokkal.
Mit épít ki valójában, ha a saját fejlesztést választja?
Magával a főkönyvvel van a legkevesebb dolog. A csapatok rendre alulbecsülik az első tételt, és csak utána jönnek rá a többi feladatra.
| Komponens | Mit foglal magában |
|---|---|
| Napló és számlák | Egyensúlyban lévő tételek, számlatükör, számlatípusok, nyitóegyenlegek |
| Változtathatatlanság (immutability) | Csak hozzáfűzhető (append-only) tárolás, sztornírozási és helyesbítási munkafolyamat, helyben történő módosítások kizárása |
| Időszaki zárás | Zárás, lezárás, késedelmes könyvelések elutasítása, ellenőrzött újranyitás naplózási adatokkal |
| Idempotencia | Kulcsok, korábbi válaszok tárolása, ütközéskezelés módosított adatkészleteknél |
| Pénzkezelés | Pontos decimális vagy váltópénz-alapú aritmetika, pénznemkódok, árfolyamok és azok forrása, kerekítési számlák |
| Áfa-motor | Országonkénti kulcsok érvényességi dátumokkal, a teljesítés helye, fordított adózás (reverse charge), adóalanynak minősülő közvetítő (deemed supplier) szabályok, adómentességek |
| Áfaalany-ellenőrzés (VAT identification checks) | Validálás a hivatalos nyilvántartás ellen, gyorsítótárazás (caching), időbélyegek, kérelemazonosítók, manuális felülvizsgálati sor a hibákhoz |
| Dokumentumok | Számlák, helyesbítő számlák, hiánytalan sorszámozás sorozatonként és évenként, PDF-generálás, kézbesítés |
| E-számlázás | Strukturált formátumok, például az EN 16931 UBL, valamint a kötelező hazai formátumok országonként |
| Banki adatok betöltése | Kivonatok importálása vagy hozzájáruláson alapuló banki kapcsolat, a már importált tranzakciók kiszűrése |
| Egyeztetés (reconciliation) | Egyeztetési szabályok, pontozás, részleges egyezések, kivételek kézi kezelése |
| Kifizetések (payouts) | Fizetési fájlok generálása, kifizetési kötegek, a kifizetések megfeleltetése az alapul szolgáló tételeknek |
| Jelentéskészítés | Főkönyvi kivonat, mérleg, eredménykimutatás, cash-flow, áfa-összesítők, lejárt követelések |
| Adónyilvántartások és bevallások | Amit az Ön országai megkövetelnek, a hatóság által elfogadott formátumban |
| Naplózás (audit) | Szereplő, művelet, entitás és magának a változásnak a lekérdezhető rögzítése minden módosításhoz |
| Megőrzés és export | Tízéves őrzési idő az OSS-rekordokhoz, teljes adatexport, védhető archívum |
A fenti tizenhét sorból nagyjából kettő az a rész, amit a legtöbb csapat elképzel, amikor azt mondja, hogy „főkönyvet fogunk építeni”.
A költségek reális felmérése
A számok minden csapattal kapcsolatban egyediek, ezért az alábbiakat inkább módszertsként kezelje, mint árajánlatként. Vegye a fenti komponenseket, rendeljen hozzájuk méretet mérnök-hétben kifejezve a saját csapatának sebessége alapján, majd alkalmazza azt a három korrekciót, amelyet a becslések általában kihagynak.
Első korrekció: a megfelelőségi komponensek nem egyszeri feladatok. Az adókulcsok változnak, a határértékek módosulnak, a formátumok átalakulnak, az EU Áfa a digitális korban (ViDA) csomagja pedig konkrét határidőkhöz kötött kötelezettségeket hoz - OSS- és IOSS-változások 2027. január 1-jétől, kiterjesztett platformszabályok 2028. július 1-jétől, határokon átnyúló digitális jelentéstétel 2030. július 1-jétől. A saját fejlesztés azt jelenti, hogy minden egyes migrációt Önnek kell elvégeznie.
Második korrekció: a helyesség biztosítása túléli a funkciófejlesztést. Az első verzió a boldog utat (happy path) kezeli. A hosszú farok (long tail) a kifizetés utáni visszatérítésekből, a részleges visszatérítésekből, a hetekkel később érkező terhelés-visszaterhelésekből, a pénznemkerekítésekből, a duplikált webhookokból és az olyan elszámolási fájlokból áll, amelyek nincsenek szinkronban az Ön adataival. Itt veszik el az idő a naptárból.
Harmadik korrekció: a könyvelő érintett (stakeholder), nem pedig ellenőr. Azok a könyvek, amelyeket egy pénzügyi szakember nem ír alá, nincsenek kész, és ez a visszajelzés túl későn érkezik egy fejlesztés során.
Egy hasznos józan eszű ellenőrzés (sanity check): árazza be a legkisebb hihető fejlesztést - főkönyv, korrekciók, időszaki lezárás, idempotencia, pénzkezelés, egy ország áfája, számlák, banki import, egyeztetés és egy alapszintű jelentéscsomag -, és hasonlítsa össze egy mérőóraszerűen árazott szolgáltatás egy évével. A Nordlet közzétett csomagjai havi 10 eurótól indulnak, 3000 kérést tartalmaznak, és havi 300 euróig terjednek 200 000 kéréssel. Ha egy fejlesztés egyetlen mérnök-év töredékébe kerül, az valós érv a fejlesztés mellett. Ha viszont több mérnök-évbe telik plusz a folyamatos karbantartásba, akkor a két opció nem is összehasonlítható, és ez a különbség minden egyes évben nő, ahogy a szabályok változnak.
Mikor indokolt valóban a saját fejlesztés?
Három eset létezik, mindegyik valós.
A főkönyve az Ön terméke. Ha olyan fizetési platformot, banki terméket vagy pénztárcát épít, ahol az egyenleg egyidejű (concurrency) műveletek alatti viselkedése a megkülönböztető jegy, akkor a főkönyv alapvető fontosságú, és az Öné kell legyen. Ilyenkor érdemes főkönyvi infrastruktúra-termékeket választani a a nulláról történő építés helyett, és külön tartani a törvényi előírások szerinti könyvelést.
A modellje nem illeszkedik egyetlen könyvelési rendszerbe sem. Egyes piactereknek valóban szokatlan elszámolási struktúrájuk van - több szereplős megosztás feltételes kifizetésekkel, letéti kezelés (escrow) szakaszos mérföldkövekkel, összetett tartalékpolitika. Ha egyik termék sem modellezi ezt, és a kikerülő megoldások rosszabbak, mint az építés, akkor építsen.
A forgalma miatt a használat alapú árazás nem kifizetődő. Megfelelően extrém tranzakciós gyakoriság mellett a kérésenkénti árazás már nem vonzó. Mielőtt erre hagyatkozna, modellezze le valós számokkal, mert az „extrém” ebben az összefüggésben magasabb, mint amit a legtöbb platform elér.
Mikor épszerűbb a vásárlás?
A vásárlás akkor győz, amikor a könyvelés kötelező, de nem megkülönböztető jegy, ami a leggyakoribb eset. Senki sem a piacterét választja azért, mert a főkönyvi tételei elegánsak. Csak akkor veszik észre, ha a könyvelés hibás.
A vásárlás akkor is a helyes döntés, ha kötelezettségei több országra is kiterjednek. Az országonkénti áfaszabályok, az adatok megőrzése és az e-számlázási kötelezettségek állandó karbantartási terhet jelentenek, egy szolgáltató viszont minden egyes ügyfél között megosztja (amortizálja) ezt a munkát. A Nordlet országonkénti EU-s áfát biztosít VIES-ellenőrzéssel, OSS- és IOSS-bevallás-számítással, i.SAF-nyilvántartásokkal és az EN 16931 UBL formátummal a Peppol számára, a termék részeként, ahelyett, hogy ez egy külön megtervezendő projekt lenne.
Az a középső út, amelyen a legtöbb csapat kiköt
A gyakorlati válasz általában nem a kettő közül az egyik. Ez a következő: vásárolja meg a főkönyvet, és építse meg a munkafolyamatot.
A könyvelési háttérrendszer kezeli a tételeket, az adókezelést, a dokumentumokat, az időszaki zárást és a naplózási nyomvonalat. Az Ön terméke pedig mindazt felügyeli, amit a felhasználók látnak, és a piacterére vonatkozó minden egyes üzleti szabályt - hogy mikor szabadítják fel az alapokat, mi a tartalékpolitika, hogyan kezelik a vitákat, és mit mutat a kereskedói irányítópult. A könyvelési API-t olyankor hívja meg, amikor a pénz elkötelezésre kerül, és megőrzi azokat a részeket, amelyek ténylegesen az Önéi.
Ez a határvonal jobban ellenáll a változásoknak is, mint az alternatívák. Egy új ország bevezetése konfigurációt jelent, nem pedig projektet. Egy új kifizetési szabály az Ön kódja, nem pedig egy szolgáltatói kérés.
Mit kell eldönteni a elköteleződés előtt?
- A főkönyve megkülönböztető jegy vagy kötelezettség? Legyen őszinte; a legtöbb kötelezettség.
- Hány országot érint, és mit követel meg mindegyik? Csak adókulcsokat, bevallásokat, nyilvántartásokat vagy adatszolgáltatást?
- Mi a stratégiája a korrekciókra? A kifizetés utáni visszatérítések és a késedelmes terhelés-visszaterhelések azok az esetek, amelyek leleplezik a gyenge tervezést.
- Ki írja alá a könyveket? Vonja be ezt a személyt a tervezés lezárása előtt, ne utána.
- Mi a tízéves megőrzési terv? Az OSS-rekordokat a tranzakció évének végétől számított tíz évig meg kell őrizni, az archívum pedig egy rendszer, nem pedig egy biztonsági mentés.
- Hogyan néz ki egy migráció három év múlva? Mindkét irányba. Építsen egy tesztexportot az első napon, és tartsa működőképesen.
FAQ
Mennyi idő alatt lehet kiépíteni egy piactéri főkönyvet?
Az egyenlegben lévő tételeket rögzítő első verzió néhány hét alatt elindítható. Az a verzió viszont, amely kezeli a kifizetés utáni visszatérítéseket, a késedelmes terhelés-visszaterheléseket, a több valutás kerekítést, a duplikált szolgáltatói webhookokat, az időszaki zárást és a könyvelő által elfogadott naplózást, lényegesen hosszabb ideig tart, és a karbantartás soha nem ér véget. A másodikra adjon becslést, mert a termelési környezet ezt jelenti.
Kezdhetjük egy balance oszloppal, és migrálhatunk később?
Lehet így is, és sokan meg is teszik, de számítson arra, hogy a migráció nehezebb lesz, mint az eredeti fejlesztés. A múltbeli adatok rekonstruálása egy módosítható egyenlegből csak akkor lehetséges, ha minden egyes eseményt megőrzött, ami azt módosította - vagyis csak akkor, ha már eleve volt főkönyve.
Helyettesíti a beépített könyvelési API a pénzügyi csapatunkat?
Nem. Eltávolítja a kézi rögzítést és egyeztetést. Valakinek továbbra is le kell zárnia a hónapot, felül kell vizsgálnia a kivételeket, szakmai döntéseket kell hoznia, és el kell készítenie a bevallásokat.
Mi a helyzet a GDPR-ral, ha a főkönyv megmásíthatatlan (immutable)?
Tartsa a pénzügyi tényeket és a pszeudonimizált hivatkozásokat a megmásíthatatlan rekordokban, a személyes adatok pedig külön rendszerben kapjanak helyet, saját megőrzési és törlési folyamattal. A megváltoztathatatlanság a pénzügyi eseményre vonatkozik, nem pedig az ahhoz csatolt minden egyes attribútumra.
Köztes megoldás-e a nyílt forráskódú könyvelési szoftver?
Ez egy valós opció, amely inkább átalakítja a költségeket, mintsem megszüntetné azokat: Ön veszi át a hosztolást, a frissítéseket, az országspecifikus lokalizációt és a jogszabályi frissítéseket. Számolja ki ezeket, mielőtt a licencdíj megspórolását tekintendőnek vélné a teljes képre nézve.