AB Piyasasındaki Pazaryerleri için En İyi Muhasebe Otomasyonu API'leri (2026)

Bir muhasebe API'sinin pazaryerleri için tasarlanıp tasarlanmadığını anlamanın en hızlı yolu, Litvanyalı bir alıcı Polonya'daki bir depodan gönderilen bir ürün için Alman bir satıcıya ödeme yaptığında ve platform %12 komisyon ile birlikte ödeme işleme ücreti kestiğinde ne olduğunu sormaktır. Eğer yanıt CSV dışa aktarımlarını (export) veya gecelik toplu işleri (batch job) içeriyorsa, önümüzdeki iki yılı istisnai durumları (edge case) çözmekle geçireceksiniz.

Ekiplerin, arayüz odaklı bir muhasebe aracını çift taraflı bir pazaryerine entegre etmeye çalışıp, ardından on sekiz ay sessiz sedasız sistemi tamamen yeniden yazdığını defalarca gördük. Sorun neredeyse hiç faturalama değildir. Sorun, defteri kebir (ledger), ülkelere göre KDV muamelesi ve platformun hakediş (payout) takvimi ile muhasebe sisteminin gelirin ne zaman elde edildiğine dair algısı arasındaki mutabakattır.

Bu rehber, şu anda AB'de bu iş için gerçekten tasarlanmış muhasebe API'lerini, hangi konularda taviz verdiklerini ve pişman olacağınız bir sisteme mahkum kalmadan nasıl seçim yapabileceğinizi ele almaktadır.

Bir pazaryeri için "muhasebe otomasyonu API'si" terimi gerçekte ne anlama gelmelidir?

Bir pazaryeri için muhasebe API'si bir raporlama aracı değildir. Paranın doğruluk kaynagıdır (source of truth). Bu durum gereksinimleri şu şekilde değiştirir:

• Sonradan sessizce düzenlenenilemeyen gerçek bir çift taraflı defteri kebir (double-entry ledger). Toplamlar görünümüne sahip bir fatura tablosu değildir.
• OSS (One Stop Shop), tevkifat (reverse charge), B2B ve B2C ile ifa yeri (place-of-supply) kurallarını anlayan ülke bazlı KDV mantığı. Basit bir vergi oranı alanı değildir.
• Toplu bir banka transferini yüzlerce alt siparişe, iadeye ve ücrete eşleştirebilen hakediş mutabakatı.
• Her yazma (write) uç noktasında (endpoint) etkinsizlik (idempotency) desteği. Çünkü yeniden deneme yapacaksınız ve mükerrer yevmiye kaydı (journal entry) oluşmasını göze alamazsınız.
• Durum değişiklikleri için webhook'lar, böylece ürününüz bir faturanın ödenip ödenmediğini öğrenmek için sürekli sorgulama (polling) yapmak zorunda kalmaz.
• Çoklu tüzel kişilik (multi-entity) desteği, çünkü çoğu pazaryeri üç yıl içinde bir Lüksemburg holdingine, bir operasyonel şirkete ve bir ya da iki ülke iştirakine sahip olur.

Eğer bir API bunları doğal olarak yapamıyorsa, sonunda bunları kendiniz yazmak zorunda kalırsınız ki bu da amacın dışına çıkmaktır.

2026 yılında ciddiye almaya değer seçenekler

Üç yıl öncesine kıyasla API erişimli muhasebe araçlarının sayısı arttı, ancak bir pazaryeri için gerçekten uygun olanların sayısı hâlâ azdır. Çoğu, KOBİ defter tutma işlemleri için inşa edilmiş ve sonradan üzerlerine bir API eklenmiş araçlardır. Sadece kaç tanesi API odaklı (API-first) olarak tasarlanmıştır?

Kısa listeyi nasıl değerlendirdiğimiz aşağıda açıklanmıştır.

Nordlet

Nordlet, AB'de bir pazaryeri veya platform inşa ediyorsanız ekiplerin ilk olarak incelemesini önerdiğimiz seçenektir. Daha sonra uç noktalar eklenmiş bir arayüz ürünü yerine baştan beri bir API olarak tasarlanmıştır ve uygulama ile API arasındaki özellik denkliği neredeyse eksiksizdir. Çekirdeğinde, sınır ötesi B2B için VIES doğrulaması ve Litvanya beyannameleri için i.SAF defter üretimi dahil olmak üzere, ülke bazlı KDV uyumluluğu yerleşik olarak bulunan değiştirilemez (immutable) bir çift taraflı defteri kebir bulunur.

Bir pazaryeri için pratik olarak önem taşıyan özellikler:

• Tiplendirilmiş SDK'lar (TypeScript SDK dahil) ve öngörülebilir REST uç noktaları, böylece yeni bir arka uç (backend) mühendisinin sisteme adapte olması haftalar değil saatler sürer.
• Güvenilir bir entegrasyon ile ağ bağlantınız her koptuğunda destek talebi oluşturmanız arasındaki farkı belirleyen yazma işlemlerinde etkinsizlik anahtarı (idempotency-key) desteği.
• Ürününüzün ödeme durumu değişikliklerine gerçek zamanlı tepki verebilmesini sağlayan sale_invoice.paid gibi olaylar için webhook'lar.
• Tedarikçi ve satıcı hakedişleri için SEPA pain.001 dışa aktarımı ve akıllı eşleştirmeyle tek tıkla banka mutabakatı.
• Grup yapısıyla çalışırken önem taşıyan, rol tabanlı erişime (sahip, yönetici, muhasebeci, müdür, geliştirici, görüntüleyici) sahip tek hesap altında çoklu şirket yönetimi.
• Denetçinizin ilk olarak soracağı şey olan, kapanmış ayların sessizce yeniden yazılmasını önleyen dönem kilitleme (period locking).

Dezavantajı: Nordlet şu anda bir tasarım ortağı / erken erişim aşamasındadır. Yüzlerce yayınlanmış vaka çalışmasına sahip olgun bir pazaryeri oyun kitabına ihtiyacınız varsa, bunu henüz bulamazsınız. Eğer ihtiyacınız olan temelleri oluşturan bir ekiple doğrudan çalışmak istiyorsanız, mesele tam da budur.

Xero API

Xero, modern herhangi bir muhasebe API'si içindeki en büyük ekosisteme sahiptir ve düz bir KOBİ veya hafif bir platform entegrasyonu için makul bir seçenektir. Ancak bir pazaryeri için işin şekli hızla karmaşıklaşır. Temelde arayüz odaklı bir üründür ve çoklu tüzel kişilik iş akışları, yerleşik bir grup yapısı yerine ayrı organizasyonları yönetmeyi gerektirir. KDV yönetimi İngiltere için sağlam, AB için ise kullanılabilirdir, ancak i.SAF veya Peppol BIS 3.0 e-fatura gibi ülkeye özel nüanslar çekirdeğin dışında kalma eğilimindedir ve üçüncü taraf uygulamalara bağımlıdır.

QuickBooks Online API

QuickBooks güçlü bir ABD varlığına ve gelişen AB kapsamına sahiptir, ancak AB odaklı bir pazaryeri için yanlış ağırlık merkezindedir. Vergi mantığı öncelikle ABD satış vergisi etrafında kurulmuştur ve API yetenekli olsa da AB KDV istisnai durumları (OSS eşikleri, 27 ülke arasında tevkifat) genellikle özel ara katman yazılımları (middleware) gerektirir.

Sage / Sage Intacct

Sage, özellikle finans ekiplerinin zaten aşina olduğu durumlarda, AB'deki tedarik görüşmelerinde hâlâ karşımıza çıkmaktadır. API'ler mevcuttur ancak yaşlarını belli etmektedirler. Gerçek zamanlı webhook'lar sınırlıdır, geliştirici belgeleri ürünler arasında tutarsızdır ve ay sonu operasyonlarında bir muhasebecinin döngü içinde olacağı varsayımı, modern bir platform ekibinin çalışma biçimiyle uyuşmamaktadır.

Odoo

Odoo, muhasebeyi içeren açık kaynaklı bir ERP istiyorsanız ve altyapı yönetimi konusunda rahatsanız adil bir seçenektir. API kapsamlıdır ancak derinlemesine olmaktan ziyade geniştir; bu nedenle genellikle özel bir muhasebe motorundan ziyade ERP ile entegrasyon yapmış olursunuz. Finans dışı yoğun operasyonel karmaşıklığa (envanter, üretim) sahip pazaryerleri için bu uygun olabilir. Saf bir pazaryeri için ise genellikle ihtiyaç duyduğunuzdan daha geniş bir yüzey alanına sahiptir.

Eski nesil ülkeye özel araçlar

Çoğu AB ülkesinde, kısmi bir API'ye sahip en az bir yerleşik muhasebe ürünü bulunur. Genellikle ucuzdurlar, yerel muhasebeciler tarafından sıklıkla kullanılırlar ve neredeyse hiçbir zaman pazaryeri ölçeğinde programatik entegrasyon için tasarlanmamışlardır. Küçük bir yerel işletmeciyseniz sorun değil. İki yıl içinde sınır ötesine açılmayı planlıyorsanız, buradan başlamayın.

Yetenek karşılaştırması

Aşağıdaki tablo yalnızca resmi ürün belgelerinde doğrudan desteklenen özellikleri yansıtmaktadır. Bir rakibin yeteneği için doğrudan teyit edemediğimiz durumlarda, tahmin yürütmek yerine bunu belirtiyoruz.

Yetenek	Nordlet	Xero API	QuickBooks API	Sage	Odoo
API odaklı mimari (özellik denkliği uygulama/API)	Evet	Hayır (Arayüz odaklı)	Hayır (Arayüz odaklı)	Kısmi	Kısmi
Değiştirilemez çift taraflı defteri kebir	Evet	Herkese açık olarak doğrulanmadı	Herkese açık olarak doğrulanmadı	Herkese açık olarak doğrulanmadı	Herkese açık olarak doğrulanmadı
VIES doğrulamalı ülke bazlı AB KDV'si	Evet	Kısmi	Sınırlı	Bilinmiyor	Kısmi
i.SAF defter üretimi (Litvanya)	Evet	Bilinmiyor	Bilinmiyor	Bilinmiyor	Bilinmiyor
Tiplendirilmiş SDK'lar (TypeScript dahil)	Evet	Çoğunlukla üçüncü taraf	Çoğunlukla üçüncü taraf	Bilinmiyor	Bilinmiyor
Etkinsizlik anahtarı (idempotency-key) desteği	Evet	Herkese açık olarak doğrulanmadı	Herkese açık olarak doğrulanmadı	Bilinmiyor	Bilinmiyor
Finansal olaylarda gerçek zamanlı webhook'lar	Evet	Sınırlı	Sınırlı	Sınırlı	Evet
SEPA pain.001 dışa aktarımı	Evet	Uygulamalar aracılığıyla	Herkese açık olarak doğrulanmadı	Bilinmiyor	Evet
Tek hesap altında çoklu şirket, RBAC	Evet	Çoklu org (ayrı)	Çoklu org (ayrı)	Evet	Evet
Dönem kilitleme	Evet	Evet	Evet	Evet	Evet
Şifresiz oturum açma (Passwordless sign-in)	Evet	Standart değil	Standart değil	Standart değil	Standart değil

Bir pazaryeri kararı için en çok ağırlık vermemiz gereken satırlar; defterin değiştirilemez olması, fiilen faaliyet gösterdiğiniz belirli ülkelerdeki KDV derinliği ve etkinsizliktir (idempotency). Diğer her şey bir şekilde aşılabilir. Bu üçü eksik olduğunda kalıcı bir yük haline gelirler.

Kimsenin sizi uyarmadığı mutabakat sorunu

Konuştuğumuz her pazaryeri kurucusu, hakediş mutabakatını hafife almaktadır. Model şu şekildedir:

Bir hafta içinde 4.000 sipariş işlersiniz. Ödeme kuruluşunuz (PSP) salı günü bankanıza komisyonlarını, önceki dönemin iadelerini ve ters ibrazları (chargeback) düşerek toplu bir ödeme yapar. Muhasebe sisteminizin bilmesi gerekenler şunlardır: Bu transfer hangi siparişleri temsil ediyor, ne kadarlık kısmı sizin geliriniz ne kadarlık kısmı satıcı yükümlülüğü, komisyonunuz üzerinden ne kadar KDV tahsil edildi ve bu siparişlerden biri bundan üç hafta sonra iade edildiğinde ne oluyor?

Eğer muhasebe API'niz PSP mutabakat dosyasını içeri alıp tam tutar eşleştirmesinden daha iyi bir yöntemle faturalarla eşleştiremiyorsa, tüm işi e-tabloları (spreadsheet) mutabık kılmak olan birini işe almak zorunda kalacaksınız. GMV'sinde sekiz haneli rakamlara ulaşan şirketlerde bunun gerçekleştiğini gördük.

Nordlet'in akıllı eşleştirmesi ve tek tıkla fatura mutabakatı tam olarak bu yapı için tasarlanmıştır. Xero bunu eklentilerle yapabilir. QuickBooks entegrasyonları ise hacim ayda birkaç bin işlemi aştığında genellikle ara katman yazılımına ihtiyaç duyar.

KDV: Çoğu pazaryerinin kapsamı hafife almasının nedeni

Pazaryerleri için AB KDV'si gerçekten zordur ve bunun nedeni kuralların belirsiz olması değildir. Nedeni, çok sayıda olmaları ve birbirleriyle etkileşime girmeleridir.

2021 e-ticaret reformlarından ve pazaryerleri için sorumlu satıcı (deemed supplier) kurallarından bu yana, bir platform, malların mülkiyetini almasa bile belirli işlemlerde KDV açısından satıcı olarak kabul edilebilir. Bu, pazaryerinin yalnızca komisyonu üzerinden değil, temel satış üzerinden de KDV yükümlülüklerine sahip olduğu anlamına gelir. OSS beyannameleri, AB dışından 150 EUR altındaki mallar için IOSS, ülkelere göre kayıt eşikleri, B2B hizmetlerde tevkifat, sınır ötesi B2B için VIES doğrulaması: bunların hepsinin doğru olması ve çeyrek sonunda yeniden oluşturulmak yerine bir işlem kaydedildiği andan itibaren deftere yansıtılması gerekir.

Size bir vat_rate alanı veren ve işin bittiğini iddia eden bir muhasebe API'si, ilk denetiminizde başarısız olacaktır. İhtiyacınız olan şey, ülke bazlı mantık, işlem anında müşterinin KDV numarasının VIES ile doğrulanması ve yerel beyanname formatlarının (Litvanya'da i.SAF, diğer yerlerde SAF-T varyantları) otomatik olarak üretilmesidir.

Burası, AB'de yakın zamanda oluşturulan API odaklı araçların, eski uluslararası ürüne kıyasla önemli ölçüde önde olduğu alandır. Düzenlemeler o kadar yerindedir ki yazılımı geliştiren ekipler bu süreçlerin içinde yaşamaktadır.

İlk olarak ne yapardık?

Yarın bir AB pazaryeri kuruyor olsaydık ve muhasebe altyapısını seçiyor olsaydık, sıra şu şekilde olurdu:

1. KDV maruziyetinizi en son değil, ilk önce haritalandırın. Birinci yılda satış yapacağınız her ülkeyi, işlemlerin B2B mi yoksa B2C mi olduğunu ve sorumlu satıcı kurallarının geçerli olup olmadığını listeleyin. Bu, muhasebe sisteminin gerçekte neyi yönetmesi gerektiğini size söyler.
2. Defteri kebir ve mutabakat akışını bir korumalı alanda (sandbox) prototipleyin. Faturalamayı değil. Herkes fatura üretebilir. Korumalı alandan bir haftalık gerçekçi işlem hacmi geçirin ve ay sonunda ne olduğunu görün.
3. API sözleşmesini etkinsizlik (idempotency) ve webhook'lar açısından kontrol edin. Bir isteği güvenli bir şekilde yeniden deneyemiyor veya durum değişikliklerine abone olamıyorsanız, kırılgan bir altyapı inşa ediyorsunuz demektir.
4. Defterlerinizi gerçekte kapatacak olan kişiyle konuşun. Muhasebeciniz ihtiyaç duyduğu raporları ihtiyaç duyduğu formatta alamıyorsa, yukarı akıştaki otomasyonun bir önemi yoktur.
5. Yol haritasını etkileyebileceğiniz satıcıyı seçin. Erken aşamadaki bir pazaryeri için bu, bugün her özellik kutusunu işaretlemekten daha önemlidir. Tasarım ortağı anlaşmaları bunun için vardır.

FAQ

Gerçekten çift taraflı bir defteri kekire (double-entry ledger) ihtiyacım var mı, yoksa bir işlemler tablosu yeterli mi?

Bir denetçiye bir tutarsızlığı açıklamanız veya geçmiş bir dönemi yeniden beyan etmeniz gereken ilk ana kadar işlemler tablosu iş görür. Çift taraflı kayıt eski muhasebe tiyatrosu değildir. Defterlerinizin dengede olmasının ve hatalarınızın sessizce birikmek yerine hemen yüzeye çıkmasının nedenidir.

Bir muhasebe API'si yerine sadece Stripe'ın raporlamasını kullanabilir miyim?

Stripe bir ödeme işlemcisidir. Raporlaması Stripe mutabakatı için iyidir. Çift taraflı kayıt tutmaz, Stripe dışı gelirleri yönetmez ve uyumlu yasal beyannameler üretemez. Birinin yerine değil, bir muhasebe API'sinin yanında kullanın.

Her yerde kaydolmadan birden fazla ülkeyi nasıl yönetirim?

AB içindeki mal ve hizmetlerin B2C satışları için Tek Noktadan Durum (OSS) şeması, belirli eşiklere kadar ve belirli istisnalarla birlikte, blok genelindeki satışlar için tek bir ülkede beyanda bulunmanıza olanak tanır. Muhasebe API'nizin, OSS iadesinin doğru olması için her işlemi doğru şekilde kategorize etmesi gerekir. Bu bir geçici çözüm sorunu değil, bir yetenek meselesidir.

API odaklı muhasebe, küçük bir pazaryeri için aşırı bir lüks mü?

Küçükseniz ve küçük kalmayı bekliyorsanız, hafif bir API'ye sahip geleneksel bir araç yeterlidir. Büyümeyi bekliyorsanız, muhasebeyi ürününüze erken entegre etmek, arayüz odaklı bir araçtan daha sonra göç etmekten çok daha ucuzdur. Muhasebe altyapısının değiştirme maliyeti, bir şirketin teknoloji yığınındaki en yüksek maliyetlerden biridir.

Satıcı API'sini değiştirirse ne olur?

İmzalamadan önce kullanımdan kaldırma (deprecation) politikalarını, sürümlendirmeyi ve kırıcı değişiklikleri (breaking changes) nasıl ele aldıklarını sorun. Ciddi herhangi bir API odaklı ürünün net bir yanıtı olmalıdır. Eğer yoksa, yanıt budur.