QuickBooks alternatívák, ha API-ra van szüksége, nem egy alkalmazásra

Miért növik ki a platformcsapatok a QuickBooksot, mit igényel a „fejlesztői felület, nem egy alkalmazás” megközelítés, és melyik alternatíva illik a leginkább a feladathoz.

A QuickBooks Online egy rátermett kisvállalkozási könyvelési szoftver nagy felhasználói bázissal, OAuth 2.0 REST API-val, webhookokkal és jelentős fejlesztői ökoszisztémával. A legtöbb csapat, amely alternatívát keres, nem magával az alkalmazással elégedetlen. Más jellegű problémával szembesültek: szoftverre van szükségük, nem egy emberre a könyvelés vezetéséhez, a QuickBooksot viszont úgy tervezték, hogy azt egy ember használja.

Ez a cikk erről a nem-megfelelésről szól, és arról, hogy mit érdemes helyette használni. Ha Ön kisvállalkozóként választ könyvelőszoftvert, a QuickBooks valószínűleg a megfelelő választás az Ön számára, és a fentiek önre nem vonatkoznak.

Ahol a nem-megfelelés megmutatkozik

Egy API-kapcsolat egyenlő egy cégfájllal. A QuickBooks API-ja egy vállalatra terjed ki, amelyet egy realm azonosít. Egy olyan platform, amely 300 eladói entitás könyvelését kezeli, 300 kapcsolatot és 300 előfizetést menedzsel, nem pedig egyetlen fiókot 300 vállalattal benne. Ez az egyetlen tényező az, ami általában véget vet az értékelésnek.

Az API az alkalmazás kiegészítője, nem maga a termék. A funkciók a felületen jelennek meg, és a saját ütemtervük szerint érkeznek meg az API-ba. Amikor az egész integráció attól függ, hogy egy funkció meghívható-e, az „elérhető az alkalmazásban” nem ugyanazt jelenti, mint az, hogy elérhető.

A korlátozást szinkronizálásra tervezték, nem tranzakciós adatfolyamra. A QuickBooks korlátozásai a széles körben dokumentált adatok szerint vállalatonként percenként 500 kérést tesznek lehetővé, a kötegelt és jelentéskészítési végpontoknál szigorúbb korlátokkal; az aktuális számokat érdemes ellenőrizni az Intuit saját fejlesztői dokumentációjában. Ez bőségesen elegendő egy vállalkozás adatainak szinkronizálásához, de teljesen más kihívást jelent, amikor a platformja valós időben könyvel le ezer vállalkozás számára indított tételeket.

Az EU-n belüli határokon átnyúló adózásban hiányosságok vannak. Az Intuit saját támogatásianyagai szerint a QuickBooksban nincs szabványos eljárás az IOSS áfa rögzítésére, és könyvelőhöz vagy adószakértőhöz irányítják a felhasználókat. Egy olyan platform esetében, amely az EU határain túlra értékesít, a távértékesítés és az egyablakos ügyintézés (OSS) kezelése nem egy ritka élvonalbeli eset, ezért ezt érdemes tisztázni az adott országok tekintetében a fejlesztés megkezdése előtt.

Eike közül sem hiba. Ezek annak a következményei, hogy kiváló alkalmazást hoztak létre olyan vállalkozások számára, amelyek könyvelőt alkalmaznak.

Mit igényel a „fejlesztői felület, nem egy alkalmazás” megközelítés?

Mielőtt összehasonlítanánk az alternatívákat, érdemes pontosan megnevezni, amit a platformcsapatok valójában kérnek, mivel a „van API-ja” feltételnek szinte minden szoftver megfelel.

Teljes lefedettség. Az alkalmazás minden funkciója meghívható. A Nordlet álláspontja itt az, hogy az alkalmazásnak nincsenek privát végpontjai, vagyis a felhasználói felület ugyanazokat a végpontokat használja, amelyeket a külső hívók is elérnek.
Több vállalat egy fiókon belül. Könyvelés számos entitás számára rengeteg külön előfizetés nélkül.
Idempotensírások. Egy újrapróbált kérés nem hozhat létre második számlát vagy duplikált könyvelési tételt.
Eseményalapú kézbesítés. Az állapotváltozásokra lefutó webhookok, így a rendszer lekérdezés helyett reagálni tud.
Kényszerített számviteli invariánsok. Az egyensúlytalan tételek elutasítása, a lezárt időszakok zárolása, a lekönyvelt dokumentumok módosíthatatlansága.
Adó mint adat, nem mint képernyő. Programozottan elérhető kulcsok, teljesítésihely-döntések, érvényesítési eredmények és nyilvántartások.
Aleset (sandbox), amely megegyezik az éles környezettel, valamint korlátlan számú tesztcég, hogy az integrációs tesztek olcsók legyenek.

Bármelyik alternatívát is értékeli, ne egy funkciótáblázathoz, hanem ehhez a listához mérje.

Az alternatívák a célok szerint csoportosítva

Az Ön helyzete	Válassza ezt	Miért?
A platformjának kell kezelnie a könyvelést számos bérlő (tenant) számára	Egy beágyazott számviteli API-t, mint például a Nordlet	Több vállalat egy fiók on belül, használatalapú árazás, a számviteli szabályok kiszolgálói oldalon történő betartatása
Az ügyfelei a QuickBooksban vezetik a könyvelésüket, és Ön integrálódik hozzájuk	Maradjon a QuickBooks API-jánál vagy használjon aggregátort	A könyvelés az ügyfél tulajdona, a helyszínen elérendő
Több könyvelési alkalmazásban kell egyszerre könyvelést vezetnie	Egy aggregátort, mint a Codat, Rutter vagy Merge	Egyetlen felület számos mögöttes rendszer felett
Valós idejű számlaegyenlegekre van szüksége, nem pedig törvényi könyvelésre	Számla-infrastruktúrát, mint a Modern Treasury Ledgers	Átviteli sebességre és módosíthatatlanságra tervezve, nem adóbevalláshoz
Egyetlen rendszert szeretne a műveletekhez és a pénzügyhez	Egy ERP-rendszert, mint az Odoo	Széleskörűség a saját üzemeltetés áráért
Ön egy könyvelővel dolgozó kisvállalkozás	Xero, QuickBooks vagy helyi megfelelő	Az alkalmazás önmagában a cél

Beágyazott számviteli API (Embedded accounting API)

Ez a közvetlen válasz a „fejlesztői felület, nem egy alkalmazás” kérdésre. A számviteli rendszer a terméke által meghívott háttérszolgáltatássá válik, és a felhasználói soha nem látnak főkönyvet.

A Nordletot ehhez a modellhez tervezték: egy módosíthatatlan kettős könyvvitelű főkönyv, ahol az egyenleget a véglegesítés pillanatában adatbázis-trigger biztosítja, hézagmentes bizonylatszámozás, lezárt hónapon belüli dátumú könyveléseket 409-es hibával elutasító időszakzárolás, minden módosításról auditnapló, Idempotency-Key támogatás, amely újrapróbáláskor a tárolt választ adja vissza, valamint az adatbázis-módosítással azonos tranzakcióban tranzakciós üzenetsorba írt aláírt webhookok. Az árazás vállalatonkénti helyett használatalapú: havi 10 eurótól indul, 3000 kérést magában foglalva, korlátlan számú vállalattal, felhasználóval és tesztcéggel minden csomagban.

A nyílt korlátok: a Nordlet korai hozzáférésű szakaszban van, és az első partnerek bevezetésénél tart; az EU-s áfa az országonkénti kulcsokat, a VIES-ellenőrzést és az OSS/IOSS bevallásszámítást fedi le, de a hazai adóbevallási csomagok jelenleg három országra érhetők el – Litvánia (FR0600), Németország (UStVA) és Lengyelország (JPK_V7M) –, a bérszámfejtés pedig csak litván piacon érhető el.

Aggregátorok

A Codat, a Rutter és a Merge egyetlen felületet biztosít ahhoz a számviteli rendszerhez, amelyet az ügyfelei már eleve használnak. Ha a termékének az a feladata, hogy az ügyfelei könyvelését olvassa vagy írja – például hitelezés, költségkezelés, elemzés –, akkor ez a megfelelő kategória, és egy beágyazott főkönyv nem lenne helyénvaló. Ha a platformjának kell a hiteles forrásrendszernek lennie, egy aggregátor erre nem alkalmas.

Főkönyvi infrastruktúra

Az ebbe a kategóriába tartozó termékek magas adatátviteli sebességgel, módosíthatatlanul követik nyomon az egyenlegeket anélkül, hogy törvényi könyvelést végeznének. Jól illeszkednek egy digitális tárca vagy fizetési termék mögé, de az áfát, a számlázást és az éves beszámolót másra bízzák.

ERP

Az Odoo és a hasonló csomagok sokkal többet fednek le a vállalkozásból, mint csak a könyvelést. A platformépítők számára a kompromisszum az integrációs felületben rejlik: az Odoo külső API-ja adatszinten működik RPC-n keresztül, a dokumentációja szerint az API-hozzáférés a Custom árszintre korlátozódik, és a jelenlegi RPC-végpontokat egy újabb JSON API-ra tervezik lecserélni. Ezt részletesen tárgyalja a Nordlet vs Odoo platformépítőknek szóló útmutató.

Ha migrál a QuickBooks rendszeréből

Néhány dolog, ami szinte biztosan több időt vesz igénybe a vártnál:

A számlatükör megfeleltetése. Végezze el tudatosan, és tartsa meg a régi számlakódot hivatkozási mezőként az új számlán. Szüksége lesz rá, amikor valaki megkérdezi, hogy miért mozdult el egy összehasonlító adat.
Nyitó egyenlegek. Egy adott határnapon lévő egyenlegekként migráljon, ne pedig utólag feltöltött előzménytörténetként. Tartsa a régi rendszert olvasható állapotban az adó megőrzési idejéig ahelyett, hogy évek tételeit próbálná visszajátszani.
Bizonylatszámozás. Döntse el, hogy az új sorozatok folytatják-e a régi számozást vagy újat kezdenek, és még a döntés előtt ellenőrizze az adott joghatóság előírásait.
Nyitott tételek. A kifizetetlen számlák, a fel nem használt jóváírások és a részben egyeztetett kifizetések nyitott tételként kell, hogy érkezzenek, nem pedig nettó egyenlegként, különben a könyvelési egyeztetés nem fog működni utána.
Adóidőszakok. Ne migráljon időszakon belül, hacsak nem kész arra, hogy egyetlen bevallást két rendszerből adjon be.
Futtassa mindkettőt egy cikluson keresztül. Könyvelje le ugyanazt a hónapot mindkét helyen, és hasonlítsa össze az alapmérleget, mielőtt lekapcsolná a régi rendszert.

FAQ

Van ingyenes alternatívája a QuickBooks rendszernek?

Léteznek ingyenes és nyílt forráskódú számviteli rendszerek, az Odoo pedig egyetlen alkalmazásra korlátozott ingyenes csomagot kínál. Az ingyenes megoldás egy platform számára ritkán marad az is, mivel a költségek áttevődnek a tárhelyre, a frissítésekre, a jogszabályi megfelelésekre és az integráció fenntartásához szükséges fejlesztési időre. A licenc helyett a teljes költséget árazza be.

Mi jobb a QuickBooks családnál egy piactér számára?

Kifejezetten a piactéri könyvelés szempontjából egy beágyazott számviteli API szerkezetileg sokkal jobban illeszkedik, mivel képes számos entitás könyvelését vezetni egyetlen fiókon belül, kiszolgálói oldalon érvényesíteni a számviteli szabályokat, és teljes egészében a szoftver által vezérelve működni. A QuickBooks továbbra is jobb termék egyetlen vállalkozás számára, amely egy könyvelővel dolgozik.

Van a QuickBooks-nak fejlesztői API-ja?

Igen. A QuickBooks Online OAuth 2.0 REST API-t kínál webhookokkal és fejlesztői portállal. A platformcélú felhasználás korlátja nem az API minősége, hanem a hatóköre: arra tervezték, hogy egy vállalat könyveléséhez kapcsolódjon, nem pedig arra, hogy egy másik termék belsejében működő főkönyv legyen.

Megtarthatom a QuickBooksot, és kiegészíthetem egy számviteli API-val?

Megteheti, és néhány csapat így is tesz: a platform saját könyvelése egy beágyazott főkönyvben él, míg az integrációk összesítő naplókat küldenek abba a számviteli rendszerbe, amelyet az egyes üzleti ügyfelek használnak. Az az elv, amelyet érdemes betartani, hogy bármilyen adatsorhoz pontosan egyetlen rendszer tartozik hiteles forrásként. Ha két rendszer is hitelesnek vallja magát, az a könyvelési egyeztetési problémák kezdete.

Mi a helyzet a Xeróval?

A Xero alkalmazásként erős alternatíva, és jól dokumentált API-val rendelkezik, de szerkezetileg ugyanilyen felépítésű: az előfizetések és az API-korlátok szervezetenként értendők, a nem hitelesített alkalmazások pedig legfeljebb 25 csatlakoztatott szervezetet kezelhetnek. Az összehasonlítást a Nordlet vs Xero beágyazott könyveléshez szóló cikk mutatja be.