Muhasebe Entegrasyon Maliyeti: Her Sağlayıcı İçin Ayrı Bir Proje
Yayınlanan tahminler, her muhasebe sistemi için üç hafta ile on iki ay arasında değişiyor ve bu emek bir sağlayıcıdan diğerine aktarılamıyor. İşte rakamlar, kaynakları ve alternatif çözüm.
Müşterilerinin muhasebe sistemlerine bağlanmak isteyen bir platform, her sağlayıcı için ayrı bir entegrasyon geliştirmek zorundadır. Tek bir entegrasyon için yayınlanan tahminler, ilk çalışan QuickBooks bağlantısı için üç ila dört hafta ile NetSuite için altı ila on iki ay arasında değişmektedir. Dahası, bulduğumuz tüm bu tahminler, bu zahmetten kurtulmanın bir yolunu satan şirketler tarafından yapılmaktadır. Emekler asla sonraki sisteme aktarılamaz: QuickBooks, Xero, NetSuite ve Microsoft Dynamics 365 Business Central; her biri kendine özgü oturum açma yöntemine, token ömrüne, sorgu sözdizimine, oran limitine (rate limit), ücrete ve sürümden kaldırma (deprecation) takvimine sahiptir. Altı sağlayıcı demek, altı ayrı proje ve altı ayrı bakım bütçesi demektir.
Bu makale, kaynaklarıyla birlikte yayınlanan rakamları derlemekte, sağlayıcıların nerede ayrıştığını göstermekte ve diğer seçeneği açıklamaktadır: Muhasebeyi tek bir muhasebe API'si aracılığıyla kendi ürününüzün içinde tutarak, her sağlayıcı için ayrı ayrı uğraşmak yerine tek bir entegrasyon inşa etmek.
Tek Bir Muhasebe Entegrasyonunun Süresi
Hiç kimse entegrasyon geliştirme sürelerine dair tarafsız bir araştırma yayınlamamaktadır. Aşağıdaki rakamların tamamı, birleştirilmiş (unified) muhasebe API'leri satan şirketlerden gelmektedir; dolayısıyla bu işi gözde büyütmek için ellerinde sebepleri vardır. Yine de bunlar mevcut en spesifik sayılardır ve "ilk çalışan sürüm" ile "canlı ortam (production)" ayrımı yaptığınızda kendi içlerinde tutarlılık gösterirler.
| Kaynak | Söyledikleri | Motivasyonları |
|---|---|---|
| Apideck (2026) | QuickBooks: "Yetenekli bir mühendis üç ila dört hafta içinde çalışır bir şeyler ortaya koyabilir." 35'ten fazla bağlayıcıyı (connector) korumak ise "en az bir mühendisin tam zamanlı olarak entegrasyon bakımına odaklanmasını gerektirir." | Birleştirilmiş API satıyor |
| Rutter (Nisan 2026) | Rutter'ın muhafazakar olarak nitelendirdiği şekliyle "Platform başına üç mühendis-ay". NetSuite için ise "bu süre altı ila on aya uzuyor". Bir müşteri QuickBooks için iki mühendisin birkaç ay çalıştığını belirtmiş, ancak süreç "birden fazla iterasyonla en az üç ay" sürmüştür. | Birleştirilmiş API satıyor |
| Merge | 150.000 dolarlık bir maaş ölçeğinde, tek bir entegrasyonu geliştirmek 150 saat, yılda bakımını yapmak ise 300 saat sürmektedir. Merge, bu maliyeti "yılda 50.000 ila 150.000 dolar" olarak hesaplıyor. | Birleştirilmiş API satıyor |
Bu rakamlarda toplam sürelerden daha önemli olan iki husus vardır.
Birincisi, üç hafta ile üç ay arasındaki fark, demo ile canlı ortam (production) arasındaki farktır. Bir faturayı oluşturan bağlantı hızla çalışır. Token süresinin dolması, mükerrer webhooks (web kancaları), oran limitleri (rate limits), kısmi hatalar ve farklı bir şirket dosyasına yeniden bağlanan bir müşterinin yarattığı durumlarla başa çıkabilen bir bağlantı ise kalan zamanı tüketir. Bulut muhasebe API'sini bir SaaS platformuna entegre etme kılavuzumuz bu süreci adım adım listelemektedir.
İkincisi, Merge'in modelinde bakım maliyeti geliştirme maliyetinden daha büyüktür: Bir defaya mahsus 150 saate karşılık yılda 300 saat bakım. Bu maliyet, desteklediğiniz her bir sağlayıcı için her yıl tekrar eder.
İkinci Entegrasyon Neden Birincisi Kadar Maliyetlidir?
Eğer sağlayıcılar aynı arayüze sahip olsaydı, ikinci entegrasyon birincisinin büyük kısmını yeniden kullanabilirdi. Ancak sahip değiller. Aşağıdaki tablo, yaygın olarak kullanılan dört sistemi karşılaştırmaktadır.
| QuickBooks Online | Xero | NetSuite | Business Central | |
|---|---|---|---|---|
| Oturum Açma (Sign-in) | OAuth 2.0 | OAuth 2.0 | OAuth 2.0; 2027.1 sürümünden itibaren yeni entegrasyonlar için token tabanlı kimlik doğrulama kapatılıyor | Yalnızca Microsoft Entra ID OAuth |
| Erişim token ömrü (Access token lifetime) | 1 saat | 30 dakika | 60 dakika | Entra ID tarafından belirlenir |
| Yenileme token'ı (Refresh token) | 100 günlük kayan (rolling), en fazla beş yıl | 60 günlük kayan (rolling) | 7 gün | Entra ID tarafından belirlenir |
| Sorgu stili | SQL benzeri SELECT … FROM Invoice, OR yok, join yok |
where parametreli REST |
REST üzerinden SuiteQL (SQL), ayrıca 2028'e kadar SOAP | OData v4 |
| Oran limiti (Rate limit) | Şirket başına dakikada 500 ve saniyede 10 istek | Şirket başına dakikada 60, günde 5.000 ve eşzamanlı (concurrent) 5 istek | Hizmet kademesine (tier) göre hesap başına eşzamanlı 5 ila 20 istek | Kullanıcı başına 5 dakikada 6.000 istek ve eşzamanlı 5 istek |
| Ayrı API ücreti | App Partner Programı: ücretsiz kademe, sonrasında ayda 300 ABD dolarından 4.500 ABD dolarına kadar | Ücretsizden ayda 1.445 Avustralya Dolarına kadar değişen uygulama planları | Bulunamadı; ek eşzamanlılık SuiteCloud Plus lisansı olarak satılıyor | Bulunamadı |
Kaynaklar: Intuit yetkilendirme SSS, Intuit limitler ve kısıtlamalar, Intuit App Partner Program kılavuzu, Xero OAuth 2.0 kılavuzu, Xero API limitleri, Xero fiyatlandırma, NetSuite OAuth 2.0 token'ları, NetSuite token tabanlı kimlik doğrulama, Business Central operasyonel limitleri.
Token'ların Süresi Dört Farklı Takvime Göre Dolar
Bir entegrasyon, her sağlayıcının token'ını süresi dolmadan önce yenilemek ve her seferinde yeni yenileme token'ını (refresh token) kaydetmek zorundadır; aksi takdirde müşterinin yeniden bağlanması gerekir. Bu takvimler arasında katlarca fark vardır: NetSuite yenileme token'ı yedi gün sürerken, QuickBooks token'ı 100 gün sürer. QuickBooks ayrıca katı bir üst sınır getirir: yenileme token'ları en fazla beş yıl geçerlidir; dolayısıyla uzun süre çalışan bağlantılar kullanımdan bağımsız olarak belirli bir tarihte sona ermeye başlayacaktır. Her takvim kendi yenileme işini (refresh job), kendi hata yönetimini ve müşteriye gönderilecek kendi "lütfen yeniden bağlanın" mesajını gerektirir.
Her Sağlayıcının Kendi Sorgu Dili Vardır
Verileri geri okumak, kodun en çok farklılaştığı alandır. QuickBooks, OR ve join (birleştirme) içermeyen, sayfa başına en fazla 1,000 kayıt döndüren kısıtlı bir SQL lehçesini kabul eder. Xero, URL içinde bir where ifadesiyle filtreleme yapar ve büyük organizasyonlar için basit eşitlik testleri önerir. NetSuite, kendi uç noktasına (endpoint) gönderilen tam bir SQL lehçesi olan SuiteQL'i kullanır. Business Central ise OData filtrelerinden yararlanır. Bir müşteri için ödenmemiş faturaları bulan bir sorgu, her birinin kendi sayfalama (paging) mekanizması ve uç durumları (edge cases) olan dört farklı kod parçası anlamına gelir.
Her Sağlayıcı Trafiği Farklı Şekilde Sınırlar
QuickBooks ve Xero, şirket başına dakikalık istekleri sayar. NetSuite ise tüm hesap genelindeki eşzamanlı istekleri hesaba katar; bu da entegrasyonunuzun, müşterinin çalıştırdığı diğer tüm entegrasyonlarla bir kotayı paylaşması ve NetSuite'in sınırın üzerindeki çağrıları reddetmesi anlamına gelir. Business Central ise beş dakikalık bir pencerede kullanıcı başına sayım yapar. Bir sağlayıcıya karşı güvenli olan toplu bir içe aktarma (bulk import) işlemi diğeri tarafından kısıtlanabilir (throttling), bu nedenle her sağlayıcı için kısıtlama ve yeniden deneme (retry) mantığı ayrı ayrı yazılmalıdır.
API Erişimi Ticari Bir İlişkidir
Dört sağlayıcıdan ikisi artık API erişimi için hacim başına ücret almaktadır. Intuit'in App Partner Programı, veri okumalarının çoğunu kapsayan "CorePlus" çağrılarını ölçer ve ücretsiz katmanda dahil edilen miktarın üzerindeki çağrıları engeller; ücretli katmanlar ise ayda 300, 1.700 ve 4.500 ABD dolarına mal olur. Xero, 2 Mart 2026 itibarıyla 5 bağlantıyla sınırlı ücretsiz plandan 10.000 bağlantı için ayda 1.445 Avustralya Dolarına kadar çıkan ücretli uygulama planlarına geçmiştir. Dolayısıyla entegrasyonun işletme maliyeti, müşterilerinizin her bir sağlayıcıyı ne sıklıkla kullandığına ve ne kadar veri okuduğunuza bağlıdır.
Sağlayıcılar Kuralları Kendi Takvimlerine Göre Değiştirir
Bugün çalışan bir entegrasyonun halihazırda duyurulmuş olan ve zorunlu olarak yeniden yazılmasını gerektirecek bir liste geçmişi vardır:
- NetSuite, 2027.1 sürümünden itibaren token tabanlı kimlik doğrulama kullanan yeni entegrasyonları kabul etmemektedir ve Oracle'ın SOAP duyurusunda "2028.2 NetSuite sürümüyle birlikte tüm uç noktaların devre dışı bırakılacağı ve SOAP tabanlı entegrasyonların çalışmayı durduracağı" belirtilmektedir (NetSuite SOAP duyurusu).
- Xero, Mart 2026'dan itibaren oluşturulan uygulamalara ayrıntılı (granular) izin kapsamları atamakta ve mevcut uygulamalara geçiş için Eylül 2027'ye kadar süre tanımaktadır (Xero OAuth 2.0 genel bakış).
- QuickBooks, yukarıda açıklanan beş yıllık yenileme token'ı üst sınırını uygulamakta ve daha eski API alt sürümlerini emekliye ayırarak 75. sürümü taban haline getirmektedir.
- Business Central online, 2022 yılında web hizmetleri için erişim anahtarlarını (temel kimlik doğrulama - basic authentication) kabul etmeyi durdurmuştur; entegrasyonlar Entra ID OAuth'a geçmek zorunda kalmıştır (Microsoft sürümden kaldırma listesi).
Bu değişikliklerin hiçbir müşteri için yeni bir özellik getirmediği açıktır. Her biri, mevcut bir bağlantının çalışmaya devam etmesini sağlamak için harcanan mühendislik süresidir ve bu süre, desteklediğiniz sağlayıcı sayısı ile çarpılır.
Altı Entegrasyon İçin Matematiksel Hesap
Rutter'ın platform başına üç mühendis-ay ve Merge'in yılda 300 bakım saati rakamlarını ele alıp bunları altı muhasebe sistemine uygulayalım:
| Tek sağlayıcı | Altı sağlayıcı | |
|---|---|---|
| Geliştirme (Build) | 3 mühendis-ay | 18 mühendis-ay |
| Yıllık bakım | 300 saat | 1.800 saat, neredeyse tam zamanlı bir mühendis |
Bunlar bizim değil, sağlayıcıların kendi varsayımlarıdır ve tek başına NetSuite bile bunları aşacaktır. Buradaki mesele orantıdır: maliyet sağlayıcı sayısı arttıkça büyür ve bakım döngüsü asla bitmez. Birleştirilmiş bir API geliştirme yükünü azaltır, ancak bu kez de her sağlayıcının veri yazma işlemlerini ve uç durumlarını ne kadar iyi desteklediğine bağımlı hale gelirsiniz ve bağlantı veya çağrı başına ödeme yaparsınız. Geliştir-veya-satın al makalemiz bunun maliyetini dürüstçe nasıl hesaplayacağınızı ele almaktadır.
Bir Kez Entegre Olun: Muhasebeyi Ürününüzün İçinde Tutun
Bağlayıcı (connector) modeli, her müşterinin defterlerinin müşterinin seçtiği bir sistemde barındırıldığını ve platformunuzun verileri oraya kopyaladığını varsayar. İkinci bir model daha vardır: platformunuz, tek bir muhasebe API'si aracılığıyla defterlerinizi kendi içinde tutar ve bunları kendi arayüzünüzde gösterir. Nordlet bunun için tasarlanmıştır. Müşterilerinizin daha önce hangi muhasebe yazılımını kullandığından bağımsız olarak, geliştirilmesi gereken tek bir entegrasyon vardır.
Nordlet'te bu tek entegrasyonun karşılığı şöyledir:
- Tek bir istek kalıbı. Her işlem
POST /v1/{module}/{resource}/{action}şeklindedir. Herlisteylemi aynı filtreyi, sıralamayı ve sayfalama gövdesini kabul eder ve her hata aynı zarfı (envelope) kullanır. Tek bir uç nokta için yazılan kod diğerleri için de aynı şekilde çalışır. Bkz. API kuralları. - Yenileme token'ları yerine API anahtarları. Bir anahtar tek bir şirkete aittir, sabit izin kapsamları taşır, belirleyeceğiniz bir son kullanma tarihine sahip olabilir ve iptal edilebilir. Döndürülecek ve saklanacak bir yenileme token'ı yoktur.
- Güvenli yeniden denemeler. Her değişiklik bir
Idempotency-Keyüst bilgisini (header) kabul eder. Aynı anahtarla bir isteği tekrarlamak, ikinci bir fatura oluşturmak yerine saklanan yanıtı döndürür. - Yeniden deneme özellikli imzalı webhooks. Olaylar, değişiklik ile aynı veritabanı işleminde yazılır, HMAC-SHA256 ile imzalanır ve yaklaşık 24 saat boyunca yeniden denenir.
- Yayınlanan tek bir oran limiti. API anahtarı başına dakikada 300 istek ve bu durum
x-ratelimit-*üst bilgileriyle raporlanır. - Dokuz dilde türü belirlenmiş (typed) SDK'lar, tek bir OpenAPI spesifikasyonundan üretilmiştir. Bkz. SDK'lar.
- Entegrasyon testi için tek bir hesap altında sınırsız korumalı alan (sandbox) şirketi.
- Tek bir fiyat listesi. Planlar istek başına ölçülür; 3.000 istek için ayda 10 €'dan başlar. Bkz. fiyatlandırma.
Çift taraflı kayıt defteri (double-entry ledger), faturalar, banka mutabakatı, KDV beyannameleri ve raporlar aynı API üzerinden erişilebilirdir; böyle bir durumda entegrasyon, verinin bir kopyasını değil, doğrudan muhasebenin kendisini kapsar. Özellikler sayfası nelerin dahil olduğunu listeler, muhasebe API'sinin ne olduğu ise modeli daha ayrıntılı olarak açıklar.
Defterleri Halihazırda Başka Yerde Olan Müşteriler
Platformunuzun bu müşteriler için normalde her sağlayıcıya özel olarak geliştirmesi gereken bağlayıcıların yerini iki şey alır:
- İçeri aktarma (Moving in). Bir şirketin hesap planı, iş ortakları, açılış bakiyeleri veya tam yevmiye geçmişi, açık faturaları, duran varlıkları ve stoku tek bir çağrıyla içe aktarılır. Bkz. başka bir sistemden geçiş yapma.
- Müşavir için dosyalar. Müşterinin mali müşaviri kendi yazılımında çalıştığı durumlarda Nordlet, defteri bu yazılımın okuyabileceği formatlarda dışarı aktarır: Alman müşavirler için bir DATEV yevmiye paketi (
POST /v1/reports/datev) ve İsveçli müşavirler için bir SIE 4 dosyası (POST /v1/reports/sie). Dosya dışa aktarımı oturum açma, token yenileme ve muhasebe sağlayıcısından çağrı başına ücret alınmasını gerektirmez.
Bağlayıcıların Hala Doğru Cevap Olduğu Durumlar
Defterleri ürününüzün içinde tutmak her platform için doğru seçim değildir:
- Müşterilerinizin finans ekipleri mevcut muhasebe sistemlerinin ana kayıt sistemi (system of record) olarak kalmasını şart koşuyorsa, doğrudan veya birleştirilmiş bir API aracılığıyla bu sistemlere bağlayıcılara ihtiyacınız vardır.
- Müşterinin defterine yalnızca sipariş başına bir fatura gibi birkaç belge göndermeniz gerekiyorsa, müşterilerinizin çoğunun kullandığı sağlayıcıya yönelik tek bir doğrudan bağlayıcı yeterli olabilir.
- Müşterilerinizin çoğu tek bir sağlayıcı kullanıyorsa, tek bir doğrudan entegrasyon altı tane değil, tek bir projeye mal olur.
"Bir kez entegre ol" argümanı, platformunuzun kullanıcılarının muhasebesini yansıtmak yerine onu bizzat çalıştırması gerektiğinde geçerlidir: satıcılara ödeme yapan pazar yerleri (marketplaces), kullanıcıları adına fatura kesen platformlar ve defter tutmanın ürünün bir parçası olduğu SaaS ürünleri. Her iki yolu da seçmeden önce, muhasebe API'si için üretim öncesi test planımız test edilmesi gerekenleri listeler.
FAQ
QuickBooks entegrasyonu ne kadar sürer?
Apideck, yetenekli bir mühendisin ilk çalışan sürümü tamamlamasının üç ila dört hafta süreceğini tahmin etmektedir. Bir Rutter müşterisi ise birkaç ay için iki mühendis öngörmüş ve birkaç iterasyonla en az üç aya ihtiyaç duymuştur. Canlı ortam çalışmaları; token yenileme, yeniden denemeler, oran limitleri, yeniden bağlanma ve mutabakat bu rakamlar arasındaki farkı oluşturur.
NetSuite entegrasyonu ne kadar sürer?
Rutter, NetSuite süresini altı ila on iki ay olarak belirlemektedir. NetSuite; hesap geneli eşzamanlılık limitleri, yedi günlük yenileme token'ları, SOAP ile birlikte SuiteQL ve 2027.1 sürümünden itibaren yeni token tabanlı kimlik doğrulama entegrasyonlarının olmayacağı ve 2028.2 sürümünde SOAP uç noktalarının devre dışı bırakılacağı yönündeki duyurulan değişikliklerle bu süreyi uzatmaktadır.
Birleştirilmiş (unified) bir muhasebe API'si her sağlayıcı için ayrı çalışmayı ortadan kaldırır mı?
Tek bir arayüz birkaç sağlayıcıyı kapsadığı için geliştirme yükünü azaltır. Ancak sağlayıcı farklarını ortadan kaldırmaz: veri yazma işlemleri, özel alanlar (custom fields) ve uç durumlar genellikle eşit düzeyde desteklenmez ve birleştirilmiş API'nin fiyatlandırması, sağlayıcıların kendi API ücretlerinin üzerine eklenir. Bu konudaki ödünleşimler SaaS entegrasyon kılavuzumuzda ele alınmaktadır.
QuickBooks ve Xero API erişiminin maliyeti nedir?
Intuit'in App Partner Programı, ücretsiz bir Builder katmanına ve aylık 300, 1.700 ve 4.500 ABD doları tutarında ücretli katmanlara sahiptir; bu katmanlarda dahil edilen miktarın üzerindeki veri okumaları ücrete tabidir. Xero'nun 2 Mart 2026 itibarıyla yürürlüğe giren uygulama planları, 5 bağlantı için ücretsiz bir plandan 10.000 bağlantı için ayda 1.445 Avustralya Dolarına kadar değişmekte olup daha büyük planlar için teklif istenmektedir.
Nordlet, müşterilerimin muhasebe sistemleriyle olan entegrasyonların yerini alabilir mi?
Platformunuz kullanıcılarının defterlerini kendi içinde tuttuğunda evet: Her muhasebe sağlayıcısı için ayrı ayrı olmak yerine Nordlet'in API'si ile tek bir entegrasyon kurarsınız. Mevcut defterler tek bir çağrıyla içe aktarılır ve DATEV veya SIE uyumlu yazılımlar kullanan mali müşavirler dışa aktarılan dosyaları teslim alır. Nordlet; QuickBooks, Xero, NetSuite veya Business Central ile senkronizasyon yapmaz; eğer bu sistemlerin ana kayıt sistemi olarak kalması gerekiyorsa, bunlara yönelik bağlayıcılara yine ihtiyacınız olacaktır.