Sektörel Rehberler
Finansal Analiz ve Yapay Zeka: Bilançonuzu AI'a Okutmak
Yapay zeka bilanço okuyabilir mi? Modelin tabloyu tam olarak nerede kaybettiği, Türkiye'ye özgü kayıt düzeni tuzağı ve güvenli bir kurulumun üç katmanı.

Yüzde 81. Finansal soru-cevap alanının en çok atıf alan ölçümü olan FinanceBench çalışmasında, halka açık şirket bildirimleri üzerinde çalıştırılan güçlü bir dil modelinin soruların bu kadarını yanlış cevapladığı ya da cevaplamayı reddettiği görüldü. Üstelik model belgeye erişebiliyordu, yani ezberden konuşmuyordu.
Bu rakamı bugünün modellerine doğrudan yapıştırmak haksızlık olur; ölçüm 2023 sonuna ait ve o günden beri modeller belirgin şekilde iyileşti. Ama ölçümün gösterdiği hata sınıfı yerinde duruyor: mali tablo, dil modelinin en rahat olduğu ortam değil.
Bu yazıda bilançonuzu yapay zekaya okutmanın nerede gerçekten işe yaradığını, hangi noktada sessizce yanlış sayı ürettiğini ve Türkiye'ye özgü bir tuzağı anlatacağız. Finans tarafındaki diğer yazılarımız gibi bu da sektör haritamızın bir parçası.
Yapay zeka bilanço okuyabilir mi?
Okuyabilir, ama "okumak" tek bir iş değil. Mali tablo analizi üç ayrı katmandan oluşur: tabloyu belgeden çıkarmak, oranları hesaplamak ve sonucu yorumlamak. Yapay zeka bu üçünün yalnızca sonuncusunda güçlü. İlk ikisini modele bırakırsanız, size gayet akıcı cümlelerle yanlış sayılar sunar.
Bu ayrımı görmek, konuyla ilgili kafa karışıklığının çoğunu çözüyor. İnsanlar modele PDF'i yükleyip "bu şirketin durumu nasıl" diye soruyor ve gelen cevabın diline bakıp ikna oluyor. Oysa cevabın kalitesi, modelin analiz yeteneğinden çok tabloyu doğru çıkarıp çıkaramadığına bağlı.
Profesyonel analiz görevlerini taklit eden FinanceQA çalışmasının bulgusu da bu yönde: mevcut modeller bu tür görevlerin yaklaşık yüzde 60'ında başarısız oluyor. Daha çarpıcı olanı FinAuditing çalışmasından geliyor; gerçek bildirimlerden türetilmiş hiyerarşik ve çok belgeli yapılarda doğruluk yüzde 60 ila 90 arasında düşüyor.
Son bulguyu bir kez daha okumakta fayda var. Tek bir tabloyu okumak ile "bilanço artı gelir tablosu artı dipnotlar artı geçen yılın rakamları" setini birlikte okumak arasındaki fark, modelin performansını yarıya indiriyor. Sizin sorduğunuz sorular ise neredeyse her zaman ikinci gruptan.
Model tabloyu tam olarak nerede kaybediyor?
Kırılma noktaları belge yapısıyla ilgili ve şaşırtıcı derecede öngörülebilir. Bunları bilmek, çıktıyı nerede kontrol edeceğinizi bilmek demek.
- Sayfa geçişleri: Model bir tablonun nerede bitip diğerinin başladığını ayırt etmekte zorlanıyor. Çok sayfalı bir mali tabloda satırlar yanlış tabloya bağlanabiliyor.
- Birleştirilmiş hücreler ve çok katmanlı başlıklar: Satır ile kolon arasındaki ilişki bozuluyor. "Cari dönem" ile "önceki dönem" kolonlarının karışması tam olarak bu sınıfa giriyor ve gözle yakalanması en zor hata türü.
- Dipnotlar: Sorun dipnotu atlamakla sınırlı değil. PDF'ten çıkarım sırasında okuma sırası karıştığı için dipnot yanlış kaleme iliştirilebiliyor, yani var olmayan bir bağ kuruluyor.
- Ölçek birimi: "Bin TL" ya da "milyon TL" ibaresi tablo başlığında bir kez geçer ve aşağıdaki her sayıyı etkiler. Bu ibarenin kaçırıldığı bir çıkarımda tüm analiz bin katı yanlış olur ve sonuç yine gayet ikna edici bir dille sunulur.
Grafik ekran görüntüsü yükleyip yorum istemek ayrı bir risk sınıfı; yanıltıcı görselleştirmeler karşısında modellerin kırılganlığı üzerine ayrıca çalışmalar var. Tabloyu metin olarak verebiliyorken resmini vermeyin.
Türkiye'ye özgü tuzak: hangi bilançoyu okutuyorsunuz?
Burası, konuyla ilgili İngilizce kaynakların hiçbirinde bulamayacağınız kısım ve Türkiye'de bir mali tabloyu AI'a okuturken karşılaşacağınız en sinsi hata kaynağı. Sorun modelde değil, girdide.
Türkiye'de defter kaydı ile finansal raporlama iki ayrı düzende yürüyor. Kamu Gözetimi Kurumu'nun kendi belgelerinde açıkça ifade ettiği gibi, bağımsız denetime tabi işletmeler finansal tablolarını TFRS veya BOBİ FRS'ye göre hazırlıyor, ancak bu bilgilerin üretildiği defter kayıtlarını 1992 tarihli tekdüzen hesap planına göre tutuyor. Kurum, mevcut tekdüzen hesap planının TFRS uyumlu tablolara doğrudan muhasebe sisteminden ulaşmak için yeterli olmadığını belirtiyor; bu yüzden raporlama tabloları ya düzeltme yapılarak ya da ayrı bir kayıt düzeni kurularak üretiliyor.
Pratikte bunun anlamı şu: aynı şirketin aynı dönemi için elinizde farklı sayılar veren birden fazla "bilanço" olabilir. Mizandan üretilmiş VUK bilançosu ile bankaya giden BOBİ FRS tablosu aynı şeyi söylemez. Modele hangisini verdiğinizi siz biliyor olmayabilirsiniz; model kesinlikle bilmiyor. İkisini aynı klasörden alıp beraber yüklerseniz, aradaki farkı "şirketin durumu" sanan bir yorum alırsınız.
Halüsinasyon tartışmasının gölgesinde kalan gerçek şu: Türkiye'de mali tablo analizinde en sık karşılaşılan hata modelin uydurması değil, yanlış tablonun yüklenmesidir.
Bu yüzden akışın en başına tek satırlık bir kural koyun: modele verdiğiniz her tablonun hangi düzene göre üretildiği dosya adında yazsın. Kulağa fazla basit geliyor, ama sahada gördüğümüz karışıklıkların büyük kısmını daha başlamadan kesiyor.
Hesabı modele yaptırmayın
Doğru mimari, sayısal işi dil modelinden alıp koda devretmektir. Model hangi hesabın yapılacağına karar verir ve bunu bir fonksiyon çağrısı olarak ifade eder; çarpma, bölme ve toplama işini gerçek bir hesaplama ortamı yapar. Finans alanına özel model çalışmaları bu tasarımı açıkça benimsiyor, yani sorunun varlığı literatürde çözüm tasarımıyla kabul edilmiş durumda.
Aynı mantık bilgi tarafında da geçerli. Muhasebe politikasını ya da bir dipnotun içeriğini modelin hafızasından beklemek yerine belgeden çekip önüne koymak gerekiyor. Bu ayrım sektörde yerleşmiş durumda: eğitim (fine-tuning) modelin davranışını şekillendirmek için, belge getirme (RAG) ise bilgi sağlamak için kullanılıyor. Hızla değişen olgusal bilgiyi modelin içine gömmeye çalışmak eskimeye ve uydurmaya açık bir yol.
Kurumsal kurulumlarda üçüncü bir katman daha var: modelin çıktısını serbest metin yerine yapılandırılmış biçimde (örneğin JSON) üretmesini zorunlu kılmak. Böylece çıktı bir insana değil, bir sonraki yazılıma konuşur ve ara adımlar denetlenebilir hale gelir.
En ucuz güvenlik ağı: tablonun kendi matematiği
Mali tablonun size hediye ettiği bir özellik var ve çoğu kurulum bunu kullanmıyor: mali tablolar her seviyede toplam içeren hiyerarşik yapılardır. Dönen varlıkların alt kalemleri toplandığında dönen varlıklar toplamını vermek zorundadır. Aktif toplamı pasif toplamına eşit olmak zorundadır.
Bu, çıkarılan veriyi sınamak için hazır bir iskelet demek. Modelin ya da çıkarım aracının ürettiği tabloyu alıp bu toplamları yeniden hesaplatın; tutmuyorsa çıkarım hatalıdır ve analize hiç geçmeyin. Hindistan'da büyük ölçekli bütçe belgeleri üzerinde yapılan 2025 tarihli bir çalışma, alan bilgisi ile algoritmik doğrulamayı birleştirerek bu yolla yüksek doğruluğa ulaştı.
Bu kontrolü kurmak birkaç satırlık iş ve modelin sessiz hatalarının çoğunu yakalıyor. Otomasyon kurarken doğrulama katmanını ihmal etmenin bedelini banka mutabakatı yazımızda da anlatmıştık; mantık aynı, ölçek farklı.
Çıkarım katmanının kendisini de modele bırakmak zorunda değilsiniz. PDF tablo çıkarımı için geliştirilmiş özel araçlar var ve bağımsız olmayan bir blog testinde çoğu sayısal tabloda yüzde 94 üzeri doğruluk raporlanıyor. Rakamı temkinle karşılayın, ama yaklaşımı ciddiye alın: önce özel araçla çıkar, sonra doğrula, en son modele yorumlat.
KOBİ için gerçekten işe yarayan senaryolar hangileri?
Yapay zekanın mali tabloda değer kattığı yer yorum katmanı olduğuna göre, işe yarayan senaryolar da yorumun pahalı olduğu yerler. Sayıyı zaten muhasebeciniz üretiyor; eksik olan çoğu zaman o sayının ne anlama geldiğinin sade bir dille açıklanması.
Sahada en çok karşılık bulan kullanımlar şunlar: kredi başvurusu öncesi oran analizinin bankanın bakacağı gözle özetlenmesi, alacak ve stok gün sayılarının nakit döngüsü diliyle anlatılması, iki dönemin karşılaştırılıp hangi kalemin neden değiştiğinin sorgulanması, ve yönetim kuruluna gidecek bir sayfalık özetin taslağının çıkarılması.
Bir senaryo daha var ki en az konuşulanı: hata avı. Modele "bu tabloda tuhaf görünen ne var" diye sormak, tutarsız kalemleri ve beklenmedik sıçramaları yakalamakta şaşırtıcı derecede iyi çalışıyor. Burada modelden kesin cevap değil, bakılacak yer listesi istiyorsunuz; bu da modelin doğal olarak iyi olduğu iş.
Geleceğe dönük tahmin isteyecekseniz beklentiyi baştan ayarlayın. Bunun sınırlarını nakit akışı tahmini yazımızda ayrı ayrı ele aldık.
Mali tablonuzu buluttaki bir modele yüklemek riskli mi?
Burada iki ayrı konu sık sık birbirine karışıyor ve ayırmak kararınızı kolaylaştırıyor. Mali tablonun kendisi kişisel veri değildir; şirketin sayılarıdır. Ancak mizan, defter dökümü ve cari hesap listeleri çalışan bordro bilgisi, ortak kimlik bilgileri ve müşteri adları içerir. Bunlar kişisel veridir ve KVKK'nın konusudur.
İkinci başlık ticari sır. Bu, kişisel veri mevzuatından bağımsız yürür ve genellikle sözleşmesel bir gizlilik yükümlülüğüne dayanır. Denetimden geçmemiş bir aracın kullanım koşullarında verinizin model eğitiminde kullanılıp kullanılmadığı yazar; sözleşmeniz varsa okumadan yüklemeyin.
Pratik orta yol: analiz edeceğiniz tabloyu isimlerden arındırıp yükleyin. Oran analizi için müşteri adına ihtiyaç yok, tutara ihtiyaç var. Bu tek adım, konunun büyük bölümünü kapsam dışına çıkarıyor. Kurumsal bir kurulum yapacaksanız verinin nerede işlendiği ayrı bir karardır ve baştan konuşulmalıdır.
Bir örnek: aynı şirket, iki farklı cari oran
Somutlaştıralım. Bir imalatçının dönen varlıkları 12.000.000 TL, kısa vadeli yükümlülükleri 8.000.000 TL görünüyor. Cari oran 1,5. Banka için makul bir tablo.
Şimdi aynı şirketin raporlama standardına göre hazırlanmış tablosuna bakalım. Stoklarında bir yıldan uzun süredir devretmeyen 2.500.000 TL'lik kalem duran varlığa alınmış ve şüpheli alacak karşılığı ayrılmış olsun. Dönen varlıklar 9.000.000 TL'ye iniyor, cari oran 1,12 oluyor.
İki sayı da doğru. Farklı sorulara cevap veriyorlar. Ama modele iki tabloyu birlikte verip "cari oranım nedir" diye sorarsanız, size ikisinden birini seçtiğini söylemeden tek bir sayı verir. Hangisini seçtiğini de çoğu zaman gerekçelendirmez.
Buradan çıkan pratik kural şu: modele soruyu sormadan önce hangi tabloya baktığınızı siz belirleyin ve prompt'un içine yazın. "Ekteki BOBİ FRS tablosuna göre" ile başlayan bir soru, "bilançoma bak" ile başlayan bir sorudan çok daha güvenilir cevap üretir.
Sık sorulan sorular
ChatGPT'ye mali tablomu yükleyebilir miyim, güvenli mi? Teknik olarak yapabilirsiniz. Kararı iki soruyla verin: yüklediğiniz belgede kişisel veri var mı ve kullandığınız hesabın koşullarında veriniz model eğitiminde kullanılıyor mu. Kurumsal planlar bu konuda farklı taahhütler veriyor. İsimlerden arındırılmış bir oran tablosu yüklüyorsanız risk büyük ölçüde düşer.
Bilanço PDF'ini Excel'e çevirip vermek daha mı doğru? Genellikle evet. PDF'ten çıkarım, hataların en çok üretildiği aşama. Elinizde muhasebe programından alınmış bir Excel ya da CSV çıktısı varsa PDF yerine onu kullanın; sayfa geçişi ve birleştirilmiş hücre sorunlarının çoğunu baştan eler.
Yapay zeka mali müşavirin yerini alır mı? Mali müşavirlik yalnızca hesap yapmak değil; beyan, sorumluluk ve mevzuat yorumu içeriyor. Yapay zeka bunların hiçbirini üstlenmiyor. Kendi verinize daha sık ve daha ucuz bakabilmenizi sağlıyor, muhatabınızı değiştirmiyor.
Model her seferinde farklı sayı veriyor, normal mi? Bu, hesabı modele yaptırdığınızın en net göstergesi. Aynı tablodan aynı oran her seferinde aynı çıkmalı. Farklı çıkıyorsa hesap katmanını koda taşımanız gerekiyor demektir.
Denetimden geçen bir tablo için de bu kontroller gerekli mi? Tablo denetlenmiş olsa bile sizin çıkarım adımınız denetlenmiş değil. Doğrulama, tablonun doğruluğunu değil, modelin tabloyu doğru okuduğunu sınıyor. İkisi ayrı şeyler.
Peki siz ne yapmalısınız?
- Üç katmanı ayırın. Çıkarım, hesap ve yorum ayrı işlerdir. Hepsini tek bir sohbet penceresine yaptırmak, hatanın nerede oluştuğunu görmenizi imkânsız kılar.
- Hangi tabloyu verdiğinizi yazın. VUK mu, BOBİ FRS mi, TFRS mi. Dosya adına yazılan tek kelime, karşılaştırma hatalarının çoğunu önler.
- Toplamları sınatın. Aktif eşittir pasif ve alt kalem toplamı eşittir ara toplam kontrolünü otomatikleştirin. Tutmuyorsa yoruma geçmeyin.
- Modelden sayı değil bakış isteyin. Oranı tabloda hesaplayın, modele "bu oran bu sektörde ne anlama gelir, neye dikkat etmeliyim" diye sorun.
- Kişisel veriyi ayıklayın. İsim, kimlik ve bordro bilgisi içeren dökümleri olduğu gibi yüklemeyin; sayılar analiz için yeterli.
- Kritik kararda ikinci göz bırakın. Kredi başvurusu, ortaklık görüşmesi ve vergi etkisi doğuran her yorum mali müşavirinizden geçsin.
Bilançoyu yapay zekaya okutmak, mali müşavirinizin yerini alma girişimi olarak kurgulandığında hayal kırıklığı yaratıyor. Sayıları hazır olan ama o sayıların ne söylediğini anlamak için kimseye danışamayan işletme sahibi için ise gerçekten kullanışlı bir ikinci okuyucu. Kendi tablolarınız üzerinde bunun nasıl kurulacağını konuşmak isterseniz bir merhaba yeter.

Yazan
Muhammet Fatih Batman
Kurucu & Editör
Web tasarım ve yazılım geliştirmede 20 yılı aşkın deneyime sahip, YZ Uzman'ın kurucusu.
Yorumlar
Henüz yorum yapılmamış. İlk yorumu sen yap!