Nevados: Denetim Çalışma Kâğıtlarını Mizandan Otomatik Üreten Platform

Müşteri

Nevados, Kamu Gözetimi Kurumu yetkisiyle çalışan bir bağımsız denetim kuruluşu ve Daxin Global'ın bağımsız üyesi. Kullanıcıları denetçiler ve denetim ekip yöneticileri.

Birlikte, denetim çalışma kâğıtlarını mizan ve muavin dosyalarından otomatik üreten bir platform geliştirdik. Arayüzü tamamen Türkçe; Finans & Fintech tarafında yürüttüğümüz işlerin en veri yoğun olanı.

Zorluk

Bağımsız denetimde işin başladığı yer şu sahne: denetçi yeni müşterinin dosyasını hazırlamak için bir önceki müşterinin Excel'ini açıp "farklı kaydet" diyor.

Bu bir özensizlik değil, mecburiyet. Çalışma kâğıdı seti denetim dosyasının kendisidir; formülleri, koşullu biçimlendirmeleri, gizli sayfaları ve makrolarıyla birlikte firmanın standardıdır. Sıfırdan üretilemez, çünkü üretilen şey artık o firmanın kâğıdı olmaz.

Sonrası elle ilerliyordu:

Veriler tek tek taşınıyordu. Mizandan hesap bakiyeleri, muavinden fiş hareketleri, ilgili kâğıda kopyalanıyordu.

Her muhasebe programı farklı konuşuyordu. Aynı mizan, farklı kolon adları, farklı hesap kodu yazımları ve farklı sayfa düzenleriyle geliyordu. Denetçi her dosyada eşlemeyi yeniden çözüyordu.

Kanıtlar elle okunuyordu. Banka teyitleri, ekstreler ve faturalar taranmış PDF olarak geliyor; denetçi dosyayı açıyor, rakamı okuyor, kâğıda yazıyor ve dosya referansını da elle giriyordu.

Karşılaştırmalı dönemler elle kuruluyordu. Cari yıl, önceki yıl ve iki önceki yıl ayrı dosyalardan derleniyordu.

Bu sürecin ürettiği asıl risk hız değil, sessizlik. Kopyalanan şablon önceki denetimin rakamlarını hücrelerinde taşıyor; temizlenmezse yeni müşterinin adı altında yayımlanıyor. Karşılaştırma dönemi yoksa cari yılı kopyalamak en kolay yol, denetim açısından en tehlikelisi. Hiçbiri ekranda hata vermiyor.

Neden otomatikleştirmesi kolay değil

Bu projeyi sıradan bir raporlama işinden ayıran tek cümle şu: Excel'i yeniden üretmek serbest değil, yerinde doldurmak zorunlu.

Bir kütüphaneye "şu veriyle yeni bir Excel yaz" demek en hızlı yol olurdu ve çıkan dosya işe yaramazdı. Çalışma kâğıdı denetim delilidir; kalite kontrolden geçer, arşivlenir. Biçimi, formülü ve makrosu dosyanın kendisi kadar önemlidir.

Bu yüzden platform şablonu dosya biçiminin iç yapısında, yerinde dolduruyor. Bunun getirdiği kurallar mimarinin merkezinde:

Hücre-Tipi Ayna İlkesi. Formül hücresi formül kalır, sabit değer sabit kalır. Bir formül hücresine değer yazmak çalışma kâğıdını sessizce bozar; üretim sonrası bu otomatik doğrulanıyor.

Önceki müşterinin verisi çıkışa sızmaz. Şablonlardan devralınan rakamlar temizleniyor ve bu bir testle güvence altında.

Eksik dönem uydurulmaz. İlk denetimlerde karşılaştırma dönemi yoksa boşluk doldurulmuyor, denetçiye uyarı olarak çıkıyor.

Makrolu dosyalar korunuyor. Makro projesi bayt düzeyinde aynı kalıyor, dosya makrolarıyla birlikte sağ çıkıyor.

Bir de Türkçeye özgü tuzak var: İ ve ı harflerinin büyük-küçük dönüşümü ayrı ele alınmazsa hesap adı eşleşmeleri sessizce kayıyor. Bu tür kuralların her biri, bir kez yaşandıktan sonra kod tabanının yazılı hafızasına eklendi.

Çözüm

Boru hattı tek yönlü: Excel girer, veritabanı kanonik veriyi tutar, Excel çıkar.

İçe aktarma ve normalleştirme

Denetçi mizan ve muavin dosyalarını yüklüyor. Sistem dosyayı profilleyip hangi muhasebe programından geldiğini tanıyor ve hesap kodlarını tek bir kanonik biçime indiriyor.

Ardından bir kolon eşleme önerisi üretiliyor ve denetçi onaylamadan veri yüklenmiyor. Yüklemede borç ve alacak toplamları karşılaştırılıyor; dengesiz bir mizan sessizce geçmiyor.

Bu noktadan sonra dosyaya bir daha bakılmıyor. MongoDB tek doğruluk kaynağı; para alanları ondalık kaybı olmayan tiple tutuluyor.

Eşleme ve mutabakat

Hesaplar standart hesap planına eşleniyor, sınıflandırılıyor. Mizan ile muavin hesap bazında karşılaştırılıp farklar denetçiye gösteriliyor. Karşılaştırmalı dönem zinciri otomatik kuruluyor.

Kanıt okuma katmanı

Denetçi taranmış kanıtı ilgili bölüme yüklüyor. Belgeyi kurum içi ağda çalışan bir dil modeli okuyor ve yapılandırılmış veri çıkarıyor. Çıkan satırlar tutara, hesap koduna veya hesap adına göre çalışma kâğıdındaki doğru satıra bağlanıyor; kaynak dosya ve sayfa numarası referans olarak damgalanıyor.

İki tasarım kararı bu katmanın tamamını belirliyor. Birincisi, belge dış bir servise gitmiyor; model kurumun kendi ağında koşuyor. İkincisi, hiçbir çıkarım otomatik uygulanmıyor; denetçi görüyor, onaylıyor, ancak ondan sonra kâğıda geçiyor. Bu, yapay zekâ entegrasyonu projelerinde savunduğumuz yaklaşımın somut hâli: model öneriyor, insan karar veriyor.

Üretim ve teslim

Üretim arka planda kuyrukta çalışıyor, denetçi ekran başında beklemiyor. Kuyruk iki kanallı; içe aktarma gibi kısa işler ile üretim ve belge okuma gibi uzun işler birbirini bloke etmiyor.

Çıktı, denetim firmasının kendi klasör düzenine uygun bir arşiv olarak teslim ediliyor; kanıt dosyaları ilgili bölümün altında duruyor.

Denetimin kendi hesapları

Platform veri taşımakla kalmıyor, denetimin hesaplarını da yapıyor: kiralama hesaplamaları, iç verim oranı, kredi itfa tabloları, merkez bankası kurlarının dönem sonu değerlemesi ve referans faizler.

Nasıl geliştirdik

Bu bölümdeki yapay zekâ, ürünün içindeki kanıt okuma katmanından ayrı bir konu. Orada müşterinin kullandığı bir özellikten, burada projenin kendisinin nasıl geliştirildiğinden söz ediyoruz.

Projeyi yapay zekâ destekli bir geliştirme akışıyla yürüttük. Ayırt edici taraf "yapay zekâya kod yazdırmak" değildi; alan kurallarını yazılı bir anayasaya dönüştürmekti.

Depoda bir kural dosyası tuttuk: modüller arası sınırlar, "şablon dokunulmazdır" ilkesi, Hücre-Tipi Ayna İlkesi, eksik dönemin doldurulmaması, önceki müşterinin verisinin sızmaması. Bu kuralların ortak özelliği şu: ihlal edildiklerinde hata vermiyorlar, sessizce yanlış çıktı üretiyorlar.

Düzeltilen her hata, tekrar etmemesi için bu dosyaya bir kural olarak geri yazıldı. Yanına kalıcı bir not dizini eklendi; her biri tek bir olguyu anlatan kısa kayıtlar. Yeni bir oturum bu birikimle başlıyor, sıfırdan değil.

Ölçülebilir tarafı: bu sürede yaklaşık 85.000 satır üretim kodu, üç dil ve üç ayrı çalışma zamanı tek depoda. Asıl kazanç ise hız değildi. Bu tip bir projede tehlikeli hatalar ekranda görünmüyor; arayüz "uygulandı" diyor, çalışma kâğıdı boş kalıyor. Kazanç, bu sessiz hataların yakalanıp bir daha olmayacak şekilde kural hâline getirilmesi oldu.

Sonuç

Proje Mayıs 2026 başında başladı, 10 Ağustos 2026'da canlıya alındı. Yaklaşık on dört hafta.

Bugün denetim bölümlerinin tamamı otomatik üretiliyor: 76 şablon dosyası, 510 sayfa, biçim ve formül kaybı olmadan dolduruluyor. Karşılaştırmalı üç dönem otomatik kuruluyor. Kanıt dosyaları çalışma kâğıdına kaynak ve sayfa referansıyla bağlanıyor.

Kalite tarafında 323 otomatik test var ve bunların bir kısmı klasik birim testi değil, alan kuralını doğruluyor: formül hücresi formül kalmalı, önceki müşterinin rakamı çıkışta olmamalı gibi. Modül sınırları da derleme zamanında test edilerek zorlanıyor.

Performans tarafında ölçülmüş bir örnek: bir üretim geçişi 14,9 saniyeden 1,1 saniyeye indi ve çıktı bayt bayt aynı kaldı. Denetimde "daha hızlı ama biraz farklı" diye bir sonuç kabul edilmiyor.

Teknoloji

.NET · MongoDB · Python · Next.js · React · TypeScript · shadcn/ui · Tailwind CSS · self-hosted LLM

Mimari modüler monolit: iş modülleri yalnızca arayüz üzerinden konuşuyor, sınırlar mimari testlerle korunuyor. Kimlik doğrulama tarafında çok faktörlü doğrulama ve tarayıcının ham token görmediği bir oturum modeli var.

Benzer bir sistem mi kuruyorsunuz?

Denetim, mali müşavirlik ya da raporlama tarafında elle doldurulan bir şablon setiniz varsa, işin zor kısmı otomasyon değil: çıktının hâlâ sizin belgeniz olarak kalması. Özel yazılım geliştirme tarafında bu tip veri yoğun ve kurallı işleri birlikte kurgulayabiliriz.