B2B'de Alacak Sigortası ve Otonom Tazminat Robotu (2026)

B2B şirketlerinde vadeli satış, ciroyu büyütürken tahsilat riskini de beraberinde getirir. Alacak sigortası bu riski poliçe koşulları kapsamında yönetmeye yardımcı olur; ancak poliçenin bulunması tek başına yeterli değildir. Alıcı limiti, sipariş, sevkiyat, fatura, vade, tahsilat, gecikme bildirimi ve hasar belgeleri farklı sistemlerde tutuluyorsa operasyonel hata riski devam eder. 2026 için asıl fırsat, bu parçaları ortak ve denetlenebilir bir veri akışında birleştirmektir.

“Otonom tazminat robotu” bu yazıda kendi başına hukuki veya finansal karar veren hazır bir ürün anlamına gelmez. Kavram; poliçe kurallarını uygulayan, ERP hareketlerini izleyen, gerekli belgeleri derleyen, eksikleri bildiren ve dosyayı yetkili kişinin onayına hazırlayan projeye özel bir otomasyon katmanını ifade eder. Nihai kapsam, sigortacının süreçleri, yürürlükteki poliçe, şirketin risk politikası ve ilgili mevzuat birlikte değerlendirilerek belirlenmelidir.

Alacak sigortası süreci neden yalnızca finans ekibinin işi değildir?

Alacak sigortasının etkinliği satış anında başlar. Satış ekibi müşteriye vade tanırken kredi risk ekibi alıcı limitini kontrol eder; operasyon teslimat ve fatura kayıtlarını oluşturur; tahsilat ekibi vadesi geçen borcu takip eder; finans ise bildirim ve hasar dosyasını yönetir. Bu zincirdeki tek bir kopukluk, sigortalı olduğu düşünülen bir işlemin eksik belge, geç bildirim veya poliçe dışı işlem nedeniyle tartışmalı hâle gelmesine yol açabilir.

Sigortacılık ve Özel Emeklilik Düzenleme ve Denetleme Kurumunun Ticari Alacak Sigortası Genel Şartları; alıcı limiti, azami vade, bildirim yükümlülükleri ve tazminatın belirlenmesi gibi temel başlıkları düzenler. Bununla birlikte her işletmede uygulanacak kontrol, poliçenin özel şartlarına ve somut satış modeline göre değişebilir. Yazılım bu nedenle sabit varsayımlara değil, sürümlenebilir poliçe kurallarına dayanmalıdır.

2026’da “otonom” yaklaşım nasıl yorumlanmalı?

Otonomluk, insanı süreçten çıkarmak değil; tekrar eden kontrolleri sistemleştirerek insanı istisna ve karar noktalarına taşımaktır. Sistem, vadesi yaklaşan faturaları belirleyebilir, tahsilat hareketlerini eşleştirebilir, limit aşımını işaretleyebilir ve hasar dosyasının taslağını hazırlayabilir. Buna karşılık poliçe yorumu, uyuşmazlık, önemli tutar, eksik kanıt veya müşteri ilişkisini etkileyen adımlar yetkili kullanıcıya yönlendirilmelidir.

Bu yaklaşım açıklanabilirlik gerektirir. Kullanıcı yalnızca “uygun değil” sonucu görmemeli; hangi müşteri, poliçe sürümü, limit, vade, fatura veya eksik belge nedeniyle bu sonucun oluştuğunu anlayabilmelidir. NIST’in gönüllü kullanıma sunduğu Yapay Zekâ Risk Yönetimi Çerçevesi de güvenilir sistemler bakımından hesap verebilirlik, şeffaflık, açıklanabilirlik, güvenlik ve insan gözetimi gibi nitelikleri öne çıkarır. Her otomasyon yapay zekâ kullanmak zorunda değildir; çoğu kritik kontrol açık iş kurallarıyla daha öngörülebilir kurulabilir.

ERP’den tazminat sonucuna uzanan ortak veri modeli

Sağlam bir mimarinin başlangıç noktası, “hangi sistem doğru kaynağı temsil ediyor?” sorusudur. ERP genellikle cari hesap, sipariş, sevkiyat, fatura, vade ve tahsilat hareketlerinin ana kaynağıdır. Poliçe ve limit bilgileri sigortacı kanalı, dosya aktarımı veya yetkili kullanıcı girişiyle gelebilir. E-posta ve belge depoları ise yazışma, teslim kanıtı ve takip belgelerini barındırabilir.

Entegrasyon katmanı bu verileri tek ekranda göstermekten fazlasını yapmalıdır. Müşteri kodları eşleştirilmeli, para birimi ve tarih formatları standartlaştırılmalı, iptal ve iade hareketleri izlenmeli, verinin hangi sistemden ve ne zaman geldiği kaydedilmelidir. Başarısız aktarımlar görünmez biçimde kaybolmamalı; yeniden deneme, sorumlu atama ve çözüm notu içeren hata kuyruğuna düşmelidir.

Temel kayıtlar neleri kapsamalı?

• Poliçe numarası, sürümü, geçerlilik dönemi, para birimi ve ilgili özel koşullar
• Alıcı kimliği, grup ilişkisi, tanımlanan limit ve limitin geçerlilik tarihleri
• Sipariş, sevkiyat, fatura, vade, tahsilat, iade ve mahsup bağlantıları
• Gecikme başlangıcı, takip girişimleri, bildirim tarihleri ve sorumlu ekip
• Hasar dosyası sürümü, belge listesi, onaylar, gönderim ve tazminat sonucu

Bu model, yakın bir operasyon alanı olan B2B sipariş takip portalı yaklaşımıyla birlikte düşünülebilir. Sipariş ve sevkiyat görünürlüğü ne kadar erken kurulursa, sigortaya konu alacağın kaynağına dönük kanıt zinciri de o kadar düzenli yönetilebilir.

Otonom tazminat robotunun iş akışı

1. Poliçe ve alıcı limiti kontrolü

Sistem, yeni sipariş veya sevkiyat öncesinde geçerli poliçe sürümünü, alıcı limitini, mevcut açık riski ve tanımlı vade koşullarını kontrol eder. Sonuç “uygun”, “onay gerekli” veya “engelli” gibi anlaşılır durumlarla sunulur. Limitin hangi işlemlerle tüketildiği kullanıcıya gösterilir; manuel istisna için gerekçe ve yetkili onayı zorunlu tutulur.

2. Fatura ve tahsilat izlemesi

ERP’den alınan faturalar vade takvimine yerleştirilir. Banka, ERP veya tahsilat sisteminden gelen hareketler güvenli eşleştirme kurallarıyla faturaya bağlanır. Kısmi ödeme, mahsup, kredi notu, iade ya da kur farkı gibi durumlar tek bir “ödendi/ödenmedi” alanına indirgenmez. Belirsiz eşleşmeler, kullanıcı incelemesi için istisna kuyruğuna gönderilir.

3. Gecikme ve bildirim yönetimi

Vade geçtiğinde sistem, poliçede tanımlanan eşiklere göre görev ve bildirim üretebilir. Satış temsilcisine müşteri iletişimi, tahsilat ekibine takip, kredi risk ekibine yeni sevkiyat değerlendirmesi atanabilir. Bildirim tarihi, kanal, alıcı yanıtı ve verilen taahhüt kaydedilir. Böylece ekipler aynı müşteriye çelişkili mesajlar göndermek yerine ortak zaman çizelgesi üzerinden çalışır.

4. Hasar dosyasının hazırlanması

Robot; fatura, sipariş, teslim belgesi, hesap ekstresi, yazışma ve tahsilat kayıtlarını tanımlı kontrol listesine göre bir araya getirir. Eksik veya tutarsız belge varsa dosyayı sessizce tamamlanmış saymaz. Eksikliği, kaynağını ve sorumlusunu gösterir. Belge değiştirildiğinde eski sürüm korunur; dosyaya kimin, ne zaman ve hangi gerekçeyle müdahale ettiği kaydedilir.

5. İnsan onayı ve güvenli gönderim

Dosya, tutar ve risk seviyesine göre yetkili kullanıcıya yönlendirilir. Dört göz ilkesi gereken işlemlerde hazırlayan ile onaylayan kişi ayrılır. Onay sonrasında sigortacının desteklediği kanal üzerinden aktarım yapılır ve teknik kabul bilgisi saklanır. Entegrasyon mevcut değilse kontrollü dışa aktarma ve manuel gönderim adımları da denetim izine eklenebilir.

6. Sonuç, muhasebe ve öğrenme döngüsü

Tazminat kararı, ödeme, kesinti, ret gerekçesi ve varsa itiraz süreci dosyaya bağlanır. ERP muhasebe kaydı otomatik taslak olarak hazırlanabilir; fakat önemli finansal kayıtlar kurumun yetki matrisine göre onaylanmalıdır. Sonuç verileri, tekrar eden eksiklikleri ve poliçe uygulamasındaki darboğazları gösterecek yönetim panellerini besler.

Rol, yetki ve istisna tasarımı

Aynı kullanıcı hem müşteri limitini değiştirebiliyor, hem istisna tanımlıyor hem de hasar dosyasını onaylıyorsa otomasyon kontrol üretmek yerine riski merkezîleştirir. Satış, finans, kredi risk, tahsilat, hukuk, operasyon ve sistem yöneticisi rolleri ayrı görevlerle tanımlanmalıdır. Tutar eşiği, şirket, bölge, müşteri grubu ve vekâlet süresi gibi koşullar yetki modeline eklenebilir.

İstisna yönetimi, sistemin çevresinden dolaşmak için kullanılan serbest metin alanı olmamalıdır. Her istisna türü; gerekçe, kanıt, süre, risk sahibi ve onaylayan kişiyle kaydedilmelidir. Benzer bir yapı, B2B siparişlerde onay akışı tasarlanırken kullanılan rol, limit ve vekâlet ilkeleriyle birlikte ele alınabilir.

Belge yönetimi ve denetim izi

Bir tazminat dosyasının güvenilirliği yalnızca belgelerin bulunmasına değil, doğru işlemle ilişkilendirilmesine bağlıdır. Belge tipi, müşteri, fatura, yükleme tarihi, yükleyen kullanıcı ve sürüm bilgisi zorunlu metadata olarak tutulmalıdır. Dosya bütünlüğü, erişim geçmişi ve saklama politikası tasarım aşamasında belirlenmelidir.

Denetim izi; kullanıcı girişi, kural sonucu, manuel değişiklik, onay, ret, veri aktarımı ve bildirim gibi olayları zaman damgasıyla kaydetmelidir. Kayıtlar sonradan sessizce değiştirilememeli; düzeltme gerekiyorsa yeni olay olarak eklenmelidir. Böylece bir dosyanın neden gönderildiği, hangi veriye dayanıldığı ve kim tarafından onaylandığı geriye dönük açıklanabilir.

Veri güvenliği nasıl planlanmalı?

Alacak sigortası yazılımı; müşteri finansal verileri, iletişim bilgileri, faturalar ve ticari belgeler gibi hassas kayıtlar işleyebilir. Bu nedenle en az yetki, güçlü kimlik doğrulama, aktarım ve depolamada şifreleme, ortam ayrımı, yedekleme, güvenlik güncellemeleri ve olay kayıtları proje kapsamına alınmalıdır. Kişisel veri işleniyorsa veri envanteri, hukuki sebep, erişim ihtiyacı ve saklama süresi ayrıca değerlendirilmelidir.

Kişisel Verileri Koruma Kurumu, alınacak önlemlerin veri sorumlusunun yapısına, faaliyetine ve risklerine uygun olması gerektiğini belirtir. Kurumun veri güvenliğine ilişkin yükümlülükler açıklaması, teknik ve idari tedbirlerin birlikte ele alınmasına yönelik resmî bir başvuru noktasıdır. Projede yalnızca yazılım güvenliği değil; kullanıcı eğitimi, yetki gözden geçirme, tedarikçi erişimi ve olay müdahalesi de değerlendirilmelidir.

Yönetim panellerinde hangi göstergeler izlenmeli?

Paneller yalnızca toplam alacak veya tazminat tutarını göstermemelidir. Karar almayı destekleyen göstergeler arasında alıcı limit kullanım oranı, vadesi yaklaşan risk, gecikme yaşlandırması, bildirime kalan süre, eksik belgeli dosyalar, onay bekleme süresi, entegrasyon hataları ve sonuçlanma durumu bulunabilir. Her metrik, kaynağına ve hesaplama kuralına kadar izlenebilmelidir.

Operasyon panosu günlük görevleri, yönetim panosu ise eğilimleri ve darboğazları öne çıkarmalıdır. Kullanıcı yalnızca grafiği değil, grafiği oluşturan dosyalara erişebilmelidir. Böylece gösterge, açıklanamayan bir rapor olmaktan çıkar ve işlem yapılabilir bir çalışma alanına dönüşür.

Projeye başlamadan önce sorulması gereken sorular

• Hangi poliçe, özel şart ve alıcı limiti verileri dijital olarak erişilebilir?
• ERP’de müşteri, fatura, vade ve tahsilat kayıtlarının kalite seviyesi nedir?
• Hangi kararlar otomatik verilebilir, hangileri insan onayı gerektirir?
• Gecikme, bildirim ve dosya teslimi için kullanılan operasyonel takvim nedir?
• Eksik veri, entegrasyon kesintisi veya kural çakışması kime atanacaktır?
• Belgeler ne kadar süre saklanacak ve kimler tarafından görüntülenebilecektir?
• Başarı; hız, hata azalması, görünürlük veya dosya kalitesiyle nasıl ölçülecektir?

İlk sürümde bütün senaryoları otomatikleştirmek yerine yüksek hacimli ve açık kurallı bir akış seçilebilir. Gölge çalışma döneminde sistemin önerileri mevcut manuel sonuçlarla karşılaştırılır. Kural isabeti, veri eksikleri ve kullanıcı davranışları gözlendikten sonra otomasyon kapsamı kontrollü biçimde genişletilir.

Kumsal Ajans ile projeye özel kapsam

Kumsal Ajans, otonom tazminat robotunu kutudan çıkan standart bir ürün iddiasıyla değil; kurumun gerçek sürecine göre tasarlanacak özel web yazılımı yaklaşımıyla ele alır. Kapsam; ERP ve üçüncü taraf entegrasyonları, rol ve yetki kurgusu, iş akışları, yönetim panelleri, belge yönetimi, bildirimler, hata ve istisna kuyrukları, veri güvenliği ve sürdürülebilir yazılım altyapısını içerebilir.

Alacak sigortası ve tazminat iş akışınızı mevcut ERP’niz, poliçe kurallarınız, veri kaynaklarınız, onay yetkileriniz ve istisnalarınız üzerinden değerlendirmek için Kumsal Ajans ile iletişime geçin. Birlikte yapılacak analizle otomasyona uygun adımlar, insan onayı gerektiren kararlar, entegrasyon sınırları ve projeye özel çözüm kapsamı belirlenebilir.