Számviteli SaaS 2026-ban: mit jelent és hogyan válasszunk

Útmutató arról, hogy mi is az a számviteli SaaS 2026-ban, hogyan különbözik a három terméktípus, és hogyan válasszuk ki azt, amelyik illeszkedik a vállalkozás tranzakció-létrehozási folyamatához.

A számviteli SaaS olyan számviteli szoftver, amelyet az interneten keresztül érünk el, a szolgáltató üzemeltet és frissít, és licencdíj helyett előfizetés alapján fizetünk érte. Az adatok a szolgáltató infrastruktúrájában tárolódnak, a frissítések a bevonásunk nélkül történnek, a jogszabályi változások pedig frissítések, nem pedig külön projektek formájában érkeznek meg.

Ez 2012-ben még hasznos megkülönböztetés volt, amikor az alternatívát az irodai számítógépre telepített program jelentette. 2026-ban szinte minden a felhőben fut, így ez a címke már nem mond sokat. A most felteendő kérdés nem az, hogy egy termék SaaS-e, hanem az, hogy a három teljesen eltérő forma közül melyikbe tartozik, mivel ez határozza meg, hogy ki használja, hogyan árazzák, és hogy képes-e lépést tartani a tranzakciós volumennel.

A számviteli SaaS három formája

Forma	Elsődleges felhasználó	Hogyan kerülnek be az adatok	Árazás alapja
Alkalmazásközpontú számvitel	Könyvelő, számviteli szakember vagy cégtulajdonos	Manuális rögzítés, banki integrációk, fájlimportok, néhány integráció	Felhasználók vagy szervezetek száma havonta
API-központú (beágyazott) számvitel	Fejlesztő, egy termék nevében	A szoftver az események történésekor hívja az API-t	Használat, jellemzően kérések vagy tranzakciók
ERP-csomag	Pénzügyi csapat és az operatív terület	A vállalkozás különböző moduljai táplálnak egy közös adatbázist	Felhasználók száma havonta, plusz bevezetés

Az alkalmazásközpontú számvitel a legnagyobb kategória a telepítések számát tekintve. A felület maga a termék; az API (ha létezik) csak kiegészítő eszköz más eszközökkel való szinkronizáláshoz. Ez a megfelelő forma, amikor egy ember felelős a könyvelésért, és a tranzakciós volumen olyan mértékű, amelyet egy ember átlátni és felügyelni tud.

Az API-központú számvitel megfordítja ezt a logikát. A felület maga az API, és az alkalmazás csupán az egyik kliense. Ez a megfelelő forma, amikor a saját szoftverünk generálja a számviteli eseményeket - például egy piactér, amely kifizetéseket számol el az eladóknak, egy SaaS-termék, amely előfizetési árbevételt könyvel, vagy egy e-kereskedelmi platform, amely határokon átnyúlóan számláz. A Nordlet itt helyezkedik el: minden modul elérhető az API-n keresztül, és az alkalmazás ugyanazokat a végpontokat használja, amelyeket a külső hívók kapnak, nincsenek eltitkolt, privát végpontok.

Az ERP-csomagok a számvitel mellett a készletkezelést, a gyártást, a CRM-et, a humánerőforrást és sok egyéb területet is lefedik. Akkor vásárolják őket, amikor a számviteli probléma elválaszthatatlan az operatív feladatoktól, és beszerzésük általában egy bevezetési projektet jelent a regisztrációs űrlap kitöltése helyett.

A legtöbb rossz szoftvervásárlás ebben a kategóriában nem a szolgáltató hibájából, hanem formabeli eltérésből adódik. Egy alkalmazásközpontú eszköz, amelyet egy platform számviteli backendjeként vásárolnak, egyedi köztes réteget (middleware) igényel majd. Egy könyvelő kiváltására vásárolt API pedig csalódást okoz majd a könyvelőnek.

Mi változott meg 2026-ra?

Négy olyan elmozdulás van, amely hatással kell, hogy legyen az idén hozott beszerzési döntésekre.

Az elektronikus számlázás országonként egyre inkább kötelezővé válik. Számos EU-tagállam már most is megköveteli a strukturált e-számlákat a belföldi B2B ügyletekben, és az EU "Áfa a digitális korban" (ViDA) csomagja is ezt az irányt jelöli ki: 2030. július 1-jétől a határokon átnyúló B2B digitális jelentéstétel áttér az e-számlázásra, a belföldi rendszerek pedig 2035. január 1-jéig igazodnak ehhez. Az a termék, amely csak PDF-et tud kibocsátani, rossz oldalon áll ebben a trendben. A strukturált formátumok számítanak - a Nordlet a kiállított számlákat és helyesbítő számlákat EN 16931 UBL formátumban állítja elő Peppol BIS 3.0 szabvány szerint, amelyre a legtöbb ilyen előírás épül.

A One Stop Shop (OSS) adatszolgáltatás 2027-ben változik. 2027. január 1-jétől az OSS és IOSS rendszerek új helyesbítési mechanizmussal, extra IOSS-információkkal és a teljesítési tagállam szerinti havi IOSS-listákkal egészülnek ki. Bármilyen eszközt is vásárol most, képesnek kell lennie arra, hogy az eredeti tranzakciókhoz kapcsolódó helyesbítéseket megőrizze, ne csak a végösszegeket.

A banki integráció alapkövetelmény, nem megkülönböztető tényező. A pénzforgalmi szolgáltatási szabályozások árucikké (commoditly) tették a hozzájáruláson alapuló banki hozzáférést. Az élő adatfolyamok ma már alapvető elvárások; ami változik, az az, hogy egy termék milyen jól párosítja a bejövő fizetést a megfelelő bizonylattal, és mit kezd azokkal, amelyeket nem tud párosítani.

A „mesterséges intelligencia a könyvelésben” ígéreteket tesztelni kell. Az automatikus kategorizálás valóban hasznos, de emellett valóban tévedhetetlen sem. A szolgáltatónak feltétendő kérdés nem az, hogy pontos-e a modell, hanem az, hogy mi történik, ha téved: a helyesbítés hagy-e maga után nyomon követhető rekordot, és egy lezárt időszak védve marad-e továbbra is?

Hogyan különböznek az árazási modellek?

A formák itt térnek el egymástól a legélesebben, és egy táblázat itt győzi le a funkciólistákat.

Modell	Jellemző rá	A költség ezzel nő	Kényelmetlen, ha
Felhasználónként havonta	Alkalmazásközpontú eszközök, ERP-csomagok	A könyveléssel foglalkozó munkatársak száma	A szoftvered, és nem emberek hozzák létre a tételeket
Szervezetenként havonta	Könyvelőket kiszolgáló alkalmazásközpontú eszközök	A jogi egységek vagy ügyfélcégek száma	Százszámra kell cégek könyvelését vezetned
Kérésen vagy tranzakciónként	API-központú eszközök	A terméked által ténylegesen generált volumen	A forgalom ingadozó és nehezen jelezhető előre

Egy konkrét példa kézzelfoghatóvá teszi a különbséget. Tegyük fel, hogy egy piactérnek saját magára, plusz 200 eladói entitásra van szüksége könyvelésre, összesen havi mintegy 40 000 számviteli művelettel.

Szervezetenkénti árazás esetén, mondjuk havi 30 euró/szervezet díj mellett, ez 201 előfizetést és havonta mintegy 6000 eurót jelent, ami szinte semmilyen kapcsolatban nincs azzal, hogy mennyi valós aktivitás történt.
Forgalomarányos (metered) árazás esetén ugyanez a munkamennyiség egyetlen fiók korlátlan számú céggel és 40 000 kéréssel. A Nordlet nyilvános csomagjai szerint ez a havi 50 eurós kategória, amely 30 000 kérést tartalmaz, plusz 10 000 további kérés darabonként 0,003 euróért, ami összesen nagyjából havi 80 euró.

A példában szereplő számok szemléltető jellegűek, a szervezetenkénti összeg pedig inkább csak helyettesítő érték, mintsem bármely konkrét szolgáltató ára. Szerkezeti szempontból az áraktól függetlenül igaz marad: a felhasználónkénti és cégenkénti árazás a szervezet alakjáért számol fel díjat, míg a forgalomarányos árazás az elvégzett munkáért. Ha az emberek végzik a munkát, a felhasználói licencek igazságos mérőszámot jelentenek. Ha a szoftver végzi a munkát, akkor nem.

Ellenőrzőlista a választáshoz

Nevezze meg az elsődleges felhasználót. Egy ember vagy egy program. Ebből a válaszból következik minden más.
Számolja meg az entitásokat. Egyetlen cég, konszolidációt igénylő cégcsoport vagy számos bérlő (tenant). A csoportkonszolidáció és a több-bérlős (multi-tenant) izoláció hasonlóan hangzik, de teljesen different problémák.
Sorolja fel az országokat. Utána kérdezze meg országonként, hogy a termék mit állít elő a valóságban: csak kulcsokat, adóbevallás-számítást, bevallásra kész regisztereket vagy közvetlen beküldést a hatóságnak. Ezek a támogatás négy különböző szintje, és a szolgáltatók mindegyikre azt mondják, hogy „támogatja az áfát”.
Ellenőrizze az írási útvonalat. Elvégezhető minden szükséges művelet az API-n keresztül, vagy bizonyos lépések csak a felületen keresztül lehetségesek? A csak felületen elérhető lépések mindörökre manuális teendők maradnak.
Tesztelje a hibajelenségeket. Ismételjen meg egy kérést (retry). Próbáljon könyvelni egy lezárt időszakba. Próbáljon meg szerkeszteni egy kiállított bizonylatot. A visszautasítások többet árulnak el, mint a sikeres műveletek.
Olvassa el az exportálási listát. Jelentések XLSX, PDF vagy JSON formátumban; adónyilvántartások a hatóság által elvárt formátumban; egy teljes főkönyvi kivonat. Ha az adatai nem tudnak távozni, a váltási költségei végtelenek lesznek.
Árazza be a saját volumenei alapján, ne pedig a szolgáltató példaügyfele szerint.
Kérdezze meg, mi történik a szabályok változásakor. Ki szállítja a frissítést, milyen ütemezésben és milyen költséggel?

Mikor rossz döntés a számviteli SaaS?

Két őszinte eset létezik.

Ha Ön egyéni vállalkozó, havi néhány számlával és egyszerű belföldi adóhelyzettel, az előfizetés többe kerülhet, mint amennyit megtakarít. Az eszközrendszer nagy forgalom, összetettség vagy mindkettő mellett éri meg a pénzét.

Ha az Ön igénye egy valós idejű egyenleg egy pénztárcában vagy fizetési termékben, és a törvényi előírások szerinti könyvelés máshol kezelt, különálló kérdés, akkor számviteli rendszer helyett főkönyvi infrastruktúrára van szüksége. A különbséget aimmutable (változtathatatlan) kettős könyvvitelű főkönyvi API-król szóló útmutatónkban mutatjuk be részletesen.

FAQ

Mit jelent a SaaS a számvitelben?

A szolgáltatásként nyújtott szoftver azt jelenti, hogy a szolgáltató üzemelteti és karbantartja a számviteli alkalmazást, Ön azt az interneten keresztül éri el, és licenc vásárlása helyett ismétlődő előfizetési díjat fizet. A frissítéseket - beleértve a jogszabályi változásokat is - a szolgáltató telepíti, nem pedig Önnek kell azokat feltennie.

Biztonságos a számviteli SaaS a pénzügyi adatok számára?

Igen, de a felteendő kérdésnek specifikusnak kell lennie, nem pedig általánosnak: hol tárolják az adatokat, ki férhet hozzájuk, hogyan kezelik a biztonsági mentéseket, mi történik az adataival, ha elhagyja a rendszert, és vezet-e a termék naplózási előzményeket minden egyes változtatásról. Az a szolgáltató, amelyik ezekre pontos választ ad, jobb benyomást kelt, mint amelyik csupán „banki szintű biztonságot” ígér.

Mi a különbség a számviteli SaaS és egy számviteli API között?

A számviteli API a számviteli SaaS egyik formája, az, amelyben a programozható felület maga a termék, nem pedig egy kiegészítő. Egy termék lehet SaaS úgy is, hogy nincs érdemi API-ja.

Mennyibe kerül a számviteli SaaS?

Ez inkább az árazási modelltől függ, mint a funkciókészlettől. A felhasználónkénti eszközök általában havi 10 és 70 euró között mozognak felhasználónként; a cégenkénti eszközök minden egyes vállalat után díjat számítanak fel; a forgalomarányos eszközök a használat alapján áraznak. A Nordlet csomagjai havi 10 eurótól indulnak, 3000 kérést tartalmazva, és minden csomag tartalmazza az összes modult, valamint a teljes API-t. Mindig modellezze a saját forgalmát, mivel ugyanaz a termék lehet olcsó vagy drága attól függően, hogy az Ön vállalkozása melyikből generál többet.

Képes a számviteli SaaS kezelni az EU-s áfát több országban is?

Némelyik képes rá, különböző mélységben. Kérdezze meg, hogy a termék csak az adókulcsokat ismeri-e, számol-e bevallást, készít-e bevallásra kész fájlt, vagy be is küld-e valamit. A Nordlet az Ön számláiból kiszámítja az OSS- és IOSS-bevallásokat az időszakon túli helyesbítésekkel együtt, és az országonkénti áfakulcs-referenciája lefedi az EU-27-et, de belföldi bevallási csomagok jelenleg három országra érhetők el - Litvánia (FR0600), Németország (UStVA) és Lengyelország (JPK_V7M) -, és a rendszer az Ön nevében semmilyen bevallást nem küld be a hatóságnak.