Emeklilik veri pipeline'ları kuran çoğu kişi, vergi hesaplamasını aşağı akış (downstream) bir problem olarak görür. Değildir. Bu, yalnızca aşağı akışta kendini gösteren — bazen on yıl sonra, bir katılımcı içeri girip tam çıkış talep ettiğinde ve stopaj motoru pipeline'ın hiç yanıtlamak üzere tasarlanmadığı bir soruyu yanıtlamak zorunda kaldığında ortaya çıkan — bir yukarı akış (upstream) problemidir.
BES'te (Bireysel Emeklilik Sistemi) çıkışta uygulanan stopaj oranı, bugünkü bakiyenin fonksiyonu değildir. O bakiyenin nasıl oluşturulduğunun fonksiyonudur: hangi katkıların ne zaman yapıldığı, her birinin sistemde ne kadar kaldığı, çıkışın gönüllü mü yoksa emeklilik hak edişi mi olduğu ve — sınır durumlarda — katılımcının geçmişindeki belirli anlarda hangi fon kompozisyonunun bulunduğu. Bu tek bir sayı değildir. Bu, boylamsal bir kayıttır.
Vergi kuralının gerçekte neye ihtiyacı var
Bir katılımcı BES'ten çıktığında, stopaj hesabı en azından şunları gerektirir:
- Her katkının tarihi ve tutarı (çalışan, işveren, devlet katkısı ayrı ayrı)
- Her katkının çıkış tarihine kadarki tutulma süresi
- Her katkı kohortuna atfedilebilen kazanç
- Çıkış nedeni (emeklilik hak edişi, gönüllü erken çıkış, vefat, maluliyet)
- Katılımcı emeklilik şirketleri arasında geçiş yaptıysa devir geçmişi
Oranlar bu girdilere göre ciddi biçimde farklılaşır. Emekliliğe hak kazanmış bir çıkış yalnızca kazançlar üzerinden %5 vergilenir. 10 yıldan önce gönüllü erken çıkış, kazançlar üzerinde %15'e kadar çıkabilir. Sınıflandırmayı yanlış yaparsanız ya fazla stopaj kesersiniz (katılımcı şikâyeti, iade süreci, düzenleyici dikkati) ya da eksik keserseniz (şirketin vergi idaresine karşı yükümlülüğü).
Pipeline'lar sessizce nerede başarısız oluyor
Çoğu BES operasyonel sistemi mevcut durum modeli etrafında tasarlanmıştır: bakiye ne, mevcut fon dağılımı ne, mevcut statü ne. Tarihsel doğruluk analitik değil, muhasebesel bir kaygı olarak ele alınmıştır. Sahada gördüğüm yaygın başarısızlık örüntüleri:
- Düzeltmede katkı kayıtlarının üzerine yazılması. Bir back-office kullanıcısı yanlış uygulanmış bir katkıyı, bir ters çevirme + yeni giriş eklemek yerine orijinal satırı düzenleyerek düzeltiyor. Denetim tablosu değişikliği yakalıyor, ama analitik katman operasyonel tablodan okuyor ve artık katkının düzeltme tarihinde yapıldığına inanıyor.
- Devir-giriş kayıtlarının tek bir açılış bakiyesine indirgenmesi. Bir katılımcı başka bir emeklilik şirketinden transfer olduğunda, alıcı şirket bunu genellikle tek bir tarihli, toplu bir giriş olarak kaydeder. Kanunun tutulma süresi için hâlâ sayılacağını söylediği orijinal katkı tarihleri bir PDF ekinde ya da serbest metin not alanında yaşar.
- Fon değişim geçmişinin yalnızca mevcut durum olarak saklanması. Katılımcı üç yıl önce hisse ağırlıklı bir fondan muhafazakâr bir fona geçti. Pipeline mevcut kompozisyonu biliyor. Ama değişim anındaki kazançların nasıl göründüğünü bilmiyor; vergi idaresi daha sonra kazançların nasıl atfedildiğini sorarsa bu önem kazanır.
- Devlet katkısının paralel bir defter olarak ele alınması. Devlet katkısının kendine özgü hak ediş kuralları ve vergi işlemi olduğundan, genellikle kendi mutabakat kadansına sahip ayrı bir sistemde saklanır. Bu iki sistem birbirinden uzaklaştığında — ki uzaklaşırlar — çıkış motoru bir sürümü seçip umut eder.
Yeniden inşa sorunu
Birisi çıkış hesaplamasının tarihsel doğruluk gerektirdiğini fark ettiğinde, tarihsel veri zaten bir yeniden inşadır. Mevcut katkı tablosunu bir denetim log'una, bir devir ekine, bir devlet katkısı beslemesine join ediyorsunuz ve kaydedilmiş bir geçmiş değil, olası bir geçmiş üretiyorsunuz.
Bu, olmayana kadar sorun değil. İki durum bunu açığa çıkarır:
- Düzenleyici denetim. SPK ya da Hazine belirli bir katılımcı için hesaplama esasını sorar. Bir hesap tablosu üretirsiniz. Her sayının nereden geldiğini sorarlar. Dört sisteme işaret edersiniz. Denetim log'unun neden analitik tablodan farklı bir katkı tarihi gösterdiğini sorarlar. Şimdi bir düzenleyiciye veri mühendisliği anlatıyorsunuz.
- Katılımcı itirazı. Kendi kayıtlarına sahip bir katılımcı — makbuzlar, banka transferleri, eski ekstreler — tutulma süresinin sistemin dediğinden daha uzun olduğunu iddia eder. Haklıysa ve fazla stopaj kestiyseniz, aradaki farkı artı itibar hasarını borçlusunuz. Haksız olduğunu kanıtlayamıyorsanız, yine borçlusunuz.
Gerçekte işe yarayan şey
Çözüm göz alıcı değil ve sonradan uyarlaması pahalı; bu yüzden ilk sancılı denetime kadar nadiren öncelik alır:
- Katkı olaylarını değişmez (immutable) olarak ele alın. Düzeltmeler, neyi düzelttiğine referans veren yeni olaylardır. Asla yerinde güncelleme yok. Bu, çoğu emeklilik operasyonel sisteminin hâlâ takip etmediği temel event-sourcing disiplinidir.
- Fon dağılımlarını ve birim fiyatlarını yalnızca fon düzeyinde değil, katılımcı düzeyinde versiyonlayın. Şunu yanıtlayabilmelisiniz: X tarihinde, bu katılımcının Y kohortu katkısı Z değerindeydi. Bu, yalnızca fon NAV geçmişini değil, katılımcı-zaman düzeyinde materyalizasyonu gerektirir.
- Devir-giriş detaylarını katkı granülaritesinde saklayın. Transfer eden şirket size bir kırılım verdiyse, yapılandırılmış olarak saklayın. Vermediyse, talep edin. Yönetmelik size bu hakkı tanıyor.
- Vergi hesaplamasını test ortamında keyfi tarihsel tarihler itibarıyla çalıştırın. Motorunuz yalnızca "bugün itibarıyla" hesaplayabiliyorsa, gerçek bir vergi motorunuz yok — bir snapshot hesaplayıcınız var. Çıkış senaryolarını tarihsel durumlar üzerinde backtest etmek, yeniden inşa boşluklarını gerçek bir katılımcı bulmadan önce yüzeye çıkarır.
- Devlet katkısı pozisyonlarını aylık değil, günlük mutabık kılın. Sapma birikir. Aylık mutabakat, herhangi bir anda 30 güne kadar farklılaşmış durum anlamına gelir ve bir çıkış talebi bu pencereye düşerse, hesaplama motorun ilk yakaladığı sayıyı kullanır.
Rahatsız edici kısım
İncelediğim çoğu BES portföyünde, tam ve hukuken temiz katkı geçmişi tek bir sorgulanabilir formda basitçe var olmayan katılımcılar bulunuyor. Bu geçmiş, resmi olarak bir yeniden inşa olduğu hiç kabul edilmemiş bir yeniden inşa olarak var. Üretilen stopaj rakamları çoğunlukla savunulabilir, ancak altta yatan veri kökeni (data lineage) yakın bir incelemeye dayanmaz.
Bu bir modelleme problemi değil. Hiçbir makine öğrenmesi yaklaşımı bunu düzeltmez. Bu, yıllar önce, çıkış vergilendirmesinin neye ihtiyaç duyacağını kimse düşünmezken alınan pipeline kararlarıyla kilitlenmiş bir veri yakalama problemidir. Ders BES'in ötesine genelleşiyor: girdileri yıllara yayılan her düzenlemeye tabi hesaplama, birinci günden itibaren tarihsel doğruluk gerektirir; çünkü onu geriye dönük olarak üretemezsiniz — yalnızca yaklaşıklayabilir ve kimsenin kontrol etmemesini umabilirsiniz.