Uygulama Değil API Aradığınızda QuickBooks Alternatifleri
Platform ekipleri neden QuickBooks'un ötesine geçiyor, "uygulama değil API" yaklaşımı gerçekte neleri gerektiriyor ve hangi alternatif hangi işe uygun?
QuickBooks Online, geniş bir kullanıcı tabanına, OAuth 2.0 REST API'ye, webhook'lara ve hatırı sayılır bir geliştirici ekosistemine sahip yetenekli bir küçük işletme muhasebe uygulamasıdır. Alternatif arayan ekiplerin çoğu bir uygulama olarak QuickBooks'tan memnuniyetsiz oldukları için bunu yapmıyor. Farklı bir sorunla karşı karşıyalar: Defterleri bir insanın değil, yazılımın tutmasını istiyorlar ve QuickBooks bir insanın tutacağı varsayımıyla inşa edilmiştir.
Bu makale söz konusu uyumsuzluğu ve bunun yerine ne kullanılacağını ele almaktadır. Eğer defter tutma yazılımı seçen küçük bir işletmeyseniz, QuickBooks sizin için doğru cevap olabilir ve burada yazılanların hiçbirisi sizi bağlamaz.
Uyuşmazlığın ortaya çıktığı noktalar
Bir API bağlantısı, bir şirket dosyası demektir. QuickBooks'un API kapsamı, bir realm (alan) ile tanımlanan şirketle sınırlıdır. İçinde 300 şirket barındıran tek bir hesap yerine, 300 satıcı varlığının defterine ihtiyaç duyan bir platform, 300 bağlantı ve 300 abonelik yönetmek zorunda kalır. Değerlendirmeyi genellikle sonlandıran tek unsur bu gerçektir.
API, ürünün kendisi değil uygulamanın bir eklentisidir. Özellikler arayüze gelir ve kendi zaman çizelgesine göre API'ye ulaşır. Tüm entegrasyonunuz bir özelliğin çağrılabilir olmasına bağlı olduğunda, "uygulamada mevcut" olması, API'de mevcut olduğu anlamına gelmez.
İstek sınırlama (throttling), işlem akışı için değil eşitleme için tasarlanmıştır. QuickBooks sınırları şirket başına dakikada 500 istek olarak belgelenmiştir; toplu işlem (batch) ve rapor uç noktalarında daha katı sınırlar bulunur. Güncel rakamları Intuit'in kendi geliştirici belgelerinden teyit etmelisiniz. Bu sınır, tek bir işletmenin kayıtlarını eşitlemek için oldukça cömerttir, ancak platformunuz binlerce işletmenin girdilerini eş zamanlı olarak kaydettiğinde farklı bir tablo ortaya çıkar.
AB sınır ötesi vergi süreçlerinde eksiklikler var. Intuit'in kendi destek materyalleri, QuickBooks'ta IOSS KDV'sini kaydetmek için standart bir prosedür olmadığını belirtmekte ve kullanıcıları bir muhasebeciye yönlendirmektedir. AB sınırları içinde satış yapan bir platform için uzaktan satış ve Tek Noktadan Durum (One Stop Shop) yönetimi istisnai bir durum değildir; bu nedenle geliştirme yapmadan önce ilgili ülkeler için bu durumu doğrulamanız gerekir.
Bunların hiçbiri birer kusur değildir. Bunlar, bir muhasebe uzmanı çalıştıran işletmeler için mükemmel bir uygulama inşa etmenin doğal sonuçlarıdır.
"Uygulama değil API" yaklaşımı gerçekte ne gerektirir?
Alternatifleri karşılaştırmadan önce, platform ekiplerinin gerçekte ne talep ettiğini adlandırmak faydalı olacaktır; çünkü "API'si var" tanımı neredeyse her sistem tarafından karşılanmaktadır.
- Tam kapsam. Uygulamanın yapabildiği her şey çağrılabilmelidir. Nordlet'in buradaki duruşu nettir: Uygulamanın özel uç noktaları yoktur - arayüz, dışarıdan gelen çağrı yapanların kullandığı uç noktalarla aynı altyapı üzerinde çalışır.
- Tek hesap altında çoklu şirket. Bir sürü abonelik açmadan birçok tüzel kişiliğin defterlerini yönetebilme.
- İşlemin mükerrer olmaması (idempotent writes). Yeniden denenen bir istek, ikinci bir fatura veya mükerrer bir yevmiye kaydı oluşturamaz.
- Olay (event) iletimi. Durum değişikliklerinde tetiklenen webhook'lar sayesinde sisteminiz yoklama (polling) yapmak yerine anlık tepki verebilir.
- Zorunlu muhasebe kuralları (invariants). Dengede olmayan kayıtların reddedilmesi, kapanan dönemlerin kilitlenmesi, kaydedilen belgelerin bir kez kesinleştikten sonra düzenlenememesi.
- Verginin bir ekran olarak değil veri olarak ele alınması. Oranlar, verginin doğduğu yer (place-of-supply) kararları, doğrulama sonuçları ve sicillere programatik olarak erişilebilmesi.
- Prodüksiyon ortamıyla eşleşen bir test (sandbox) ortamı ve entegrasyon testlerinin maliyetsiz olması için sınırsız test şirketi.
Herhangi bir alternatifi bir özellik matrisine göre değil, yukarıdaki listeye göre değerlendirin.
Ne yapmaya çalıştığınıza göre alternatifler
| Durumunuz | Yönelmeniz gereken | Neden |
|---|---|---|
| Platformunuz pek çok kiracının defterine sahip olmak zorunda | Nordlet gibi gömülü (embedded) bir muhasebe API'si | Tek hesap altında çoklu şirket, kullanım bazlı fiyatlandırma, sunucu tarafında uygulanan muhasebe kuralları |
| Müşterileriniz defterlerini QuickBooks'ta tutuyor ve siz onlarla entegre oluyorsunuz | QuickBooks API'sinde kalın veya bir toplayıcı (aggregator) kullanın | Defterler müşteriye aittir, onlara kendi alanlarında eşlik etmek doğrudur |
| Aynı anda birkaç muhasebe uygulamasında defter tutmanız gerekiyor | Codat, Rutter veya Merge gibi bir toplayıcı | Birçok alttaki sistem üzerinde tek bir arayüz |
| Yasal defterlere değil, gerçek zamanlı cüzdan bakiyelerine ihtiyacınız var | Modern Treasury Ledgers gibi defter (ledger) altyapıları | Vergi beyannamesi için değil, yüksek işlem hacmi ve değiştirilemezlik (immutability) için tasarlanmıştır |
| Operasyon ve finans genelinde tek bir sistem istiyorsunuz | Odoo gibi bir ERP | Kendiniz çalıştırmanın getirdiği maliyet karşılığında sunduğu geniş kapsam |
| Bir muhasebeciyle çalışan küçük bir işletmesiniz | Xero, QuickBooks veya yerel bir eşdeğer | Uygulamanın kendisi asıl amaçtır |
Gömülü (embedded) muhasebe API'si
Bu yaklaşım, "uygulama değil API" talebine doğrudan verilen yanıttır. Muhasebe sistemi, ürününüzün arka planda çağrı yaptığı bir servise dönüşür ve kullanıcılarınız hiçbir zaman genel mizan (general ledger) ekranlarıyla karşılaşmaz.
Nordlet tam olarak bu amaç için tasarlanmıştır: İşlem anında (commit time) bir veritabanı tetikleyicisiyle bakiyenin kesinleştirildiği değiştirilemez çift taraflı defter (immutable double-entry ledger), boşluksuz belge numaralandırma, kapalı bir ay içine tarihlenen kayıtları 409 hatasıyla reddeden dönem kilitleme, her değişikliğin denetim kaydı, yeniden denemelerde saklanan yanıtı döndüren Idempotency-Key desteği ve değişiklik ile aynı veritabanı işleminde (transaction) yazılan imzalı webhook'lar sunar. Fiyatlandırma şirket başı değil, kullanım başına modellenmiştir: 3.000 istek dahil aylık 10 €'dan başlar ve her planda sınırsız şirket, kullanıcı ile sandbox şirketi sunulur.
Dürüstçe ifade etmek gerekirse sınırlamalarımız şunlardır: Nordlet erken erişim aşamasında olup tasarım ortaklarını kabul etmektedir; AB KDV'si ülke bazlı oranları, VIES doğrulamasını ve OSS/IOSS beyanname hesaplamasını kapsar, ancak yerel beyanname paketleri şu an için yalnızca üç ülkede sunulmaktadır - Litvanya (FR0600), Almanya (UStVA) ve Polonya (JPK_V7M) - ve bordro yalnızca Litvanya için geçerlidir.
Toplayıcılar (Aggregators)
Codat, Rutter ve Merge; müşterinizin halihazırda kullandığı herhangi bir muhasebe sistemine tek bir arayüzden erişmenizi sağlar. Ürününüzün amacı müşterilerinizin defterlerini okumak veya yazmaksa -örneğin borç verme, harcama yönetimi, analitik- doğru kategori budur ve gömülü bir defter bu senaryoda yanlış seçim olacaktır. Platformunuz ana kayıt sistemi (system of record) olmak zorundaysa, bir toplayıcı bu rolü üstlenemez.
Defter altyapıları
Bu kategorideki ürünler, yasal muhasebe yapmadan yüksek işlem hacmiyle bakiyeleri değiştirilemez şekilde takip eder. Cüzdan veya ödeme ürünleri için uygundur; ancak KDV, faturalandırma ve yıllık raporlama gibi süreçleri başka bir sisteme bırakırlar.
ERP
Odoo ve benzeri paketler, muhasebenin çok ötesinde işletmenin birçok alanını kapsar. Platform geliştiricileri için bu durumun dezavantajı entegrasyon yüzeyidir: Odoo'nun harici API'si RPC üzerinden veri modeli düzeyinde çalışır, belgelerinde API erişiminin Custom fiyatlandırma katmanıyla sınırlı olduğu belirtilir ve mevcut RPC uç noktalarının daha yeni bir JSON API ile değiştirilmesi planlanmaktadır. Bu konu Platform geliştiricileri için Nordlet ve Odoo karşılaştırmasında ele alınmıştır.
QuickBooks'tan başka bir sisteme geçiyorsanız
Beklenenden daha uzun süren birkaç rutin süreç şunlardır:
- Hesap planı eşlemesi. Bu adımı bilinçli bir şekilde yapın ve eski hesap kodunu yeni hesapta bir referans alanı olarak saklayın. Karşılaştırmalı bir rakamın neden değiştiği sorulduğunda buna ihtiyacınız olacak.
- Açılış bakiyeleri. Geçmişi yeniden deftere işlemek yerine, belirli bir kesişim tarihindeki bakiyeler olarak geçiş yapın. Yıllarca süren kayıtları baştan oynatmaya çalışmak yerine, yasal saklama süresi boyunca eski sistemi okunabilir tutun.
- Belge numaralandırma. Yeni serinin eski numaralandırmaya devam edip etmeyeceğine veya sıfırdan mı başlayacağına karar verin ve seçim yapmadan önce yerel mevzuattaki gereklilikleri kontrol edin.
- Açık kalemler. Ödenmemiş faturalar, mahsuplaşmamış alacaklar ve kısmen eşleşmiş ödemeler net bakiyeler olarak değil açık kalemler olarak aktarılmalıdır, aksi takdirde mutabakat çalışmaz.
- Vergi dönemleri. İki farklı sistemden tek bir beyanname vermeye hazır değilseniz, dönem ortasında geçiş yapmayın.
- Bir döngü boyunca her iki sistemi de çalıştırın. Aynı ayı her iki sistemde de deftere işleyin ve eski sistemi kapatmadan önce mizanı (trial balance) karşılaştırın.
FAQ
QuickBooks'un ücretsiz bir alternatifi var mı?
Ücretsiz ve açık kaynaklı muhasebe sistemleri mevcuttur ve Odoo tek bir uygulamayla sınırlı ücretsiz bir katman sunar. Bir platform için ücretsiz olan nadiren ücretsiz kalır; çünkü maliyetler barındırma (hosting), güncellemeler, uyumluluk güncellemeleri ve entegrasyonun çalışır durumda tutulması için harcanan mühendislik süresine kayar. Lisans fiyatına değil, toplam maliyete odaklanın.
Pazar yerleri için QuickBooks'tan daha iyi olan nedir?
Özellikle pazar yeri muhasebesi için gömülü bir muhasebe API'si yapısal olarak çok daha uygundur; çünkü tek bir hesap altında pek çok tüzel kişiliğin defterini tutabilir, sunucu tarafında muhasebe kurallarını uygulayabilir ve tamamen yazılımınız tarafından yönetilebilir. QuickBooks, bir muhasebecisi olan tekil bir işletme için daha iyi bir üründür.
QuickBooks'un geliştiriciler için bir API'si var mı?
Evet. QuickBooks Online, webhook'lar ve bir geliştirici portalı içeren bir OAuth 2.0 REST API sunar. Platform kullanımı açısından kısıtlayıcı olan faktör API'nin kalitesi değil kapsamıdır: Bu API, bir şirketin defterleriyle entegre olmak için tasarlanmıştır, başka bir ürünün içindeki defter sistemi olmak için değil.
QuickBooks'u tutup buna ek olarak bir muhasebe API'si kullanabilir miyim?
Evet yapabilirsiniz ve bazı ekipler bunu tercih etmektedir: Platformun kendi defterleri gömülü bir defterde tutulurken, entegrasyonlar özet yevmiyeleri her kurumsal müşterinin kendi kullandığı muhasebe sistemine iletir. Unutmamanız gereken temel kural, herhangi bir defter seti için kesinlikle tek bir sistemin ana kayıt kaynağı (record) olması gerektiğidir. İki sistemin de yetkili olduğunu iddia etmesi mutabakat sorunlarının başlangıcıdır.
Peki ya Xero?
Xero bir uygulama olarak güçlü bir alternatiftir ve iyi belgelenmiş bir API'ye sahiptir, ancak aynı yapısal özelliklere sahiptir: abonelikler ve API sınırları organizasyon başına uygulanır ve sertifikasız uygulamalar en fazla 25 bağlı organizasyonla sınırlandırılmıştır. Karşılaştırma Gömülü muhasebe için Nordlet ve Xero karşılaştırmasında detaylandırılmıştır.