Yapay Zeka ile Fatura ve Döküman Okuma: OCR + LLM İş Akışına Nasıl Oturur?

Her ayın başında aynı sahne tekrarlanıyor: muhasebeci ya da ofis asistanı kutu dolusu faturayı tek tek açıyor, tutar, tarih, KDV ve tedarikçi bilgisini elle muhasebe programına giriyor. Yüz elli fatura, günde birkaç saat, ve bir yerde mutlaka bir rakam yanlış yazılıyor. Yapay zeka ile fatura ve döküman okuma tam olarak bu işi bir insanın hızından çıkarıp saniyelere indiren teknoloji — ama nasıl çalıştığını ve nerede hâlâ insan gözüne ihtiyaç duyduğunu bilmek işin can alıcı kısmı.

##OCR nedir, yapay zekanın (LLM) işe eklediği fark ne?

OCR (optik karakter tanıma), bir görüntüdeki pikselleri harflere ve rakamlara çeviren, onlarca yıldır var olan bir teknoloji. Taranmış bir faturaya OCR uygularsan çıktı olarak düz bir metin yığını alırsın: 'ABC Ticaret Ltd. Şti. Fatura No: 2026-4471 Tarih: 12.08.2026 Ara Toplam: 12.450,00 KDV %20: 2.490,00 Genel Toplam: 14.940,00'. OCR bu metni doğru çıkarabilir ama hangi rakamın 'ara toplam', hangisinin 'genel toplam' olduğunu anlamaz — sadece karakterleri tanır, yapıyı değil.

İşte LLM tam burada devreye giriyor. OCR çıktısını (ya da görüntüyü doğrudan görebilen modern çok-modlu modellerde ham görseli) bir dil modeline verip 'bu bir fatura, şu alanları JSON olarak çıkar' dediğinde model, insan gibi bağlamdan anlam çıkarır: hangi tutarın toplam olduğunu, tedarikçi adının nerede geçtiğini, satır kalemlerinin nasıl gruplandığını çözer — üstelik her tedarikçinin fatura şablonu farklı olsa bile. Klasik OCR + kural tabanlı ayrıştırma her yeni fatura formatı için ayrı bir şablon ister; LLM tabanlı okuma format değişse de genelleşir. Fark, tam olarak burada: biri karakter tanıyor, diğeri anlam çıkarıyor.

##Sistem gerçekte nasıl çalışıyor: adım adım

• ▸Fatura e-posta, WhatsApp, tarayıcı ya da mobil fotoğraf olarak sisteme girer
• ▸Görüntü ön işlemeden geçer (eğim düzeltme, kontrast, gereksiz kenarların kırpılması)
• ▸OCR katmanı ham metni çıkarır (ya da çok-modlu model görseli doğrudan işler)
• ▸LLM, önceden tanımlı bir şemaya göre alanları yapılandırır: tedarikçi, tarih, fatura no, ara toplam, KDV oranı ve tutarı, genel toplam, satır kalemleri
• ▸Doğrulama kuralları çalışır: ara toplam + KDV = genel toplam mı, aynı fatura no daha önce işlenmiş mi (mükerrer kayıt kontrolü), tutar makul bir aralıkta mı
• ▸Güven skoru düşük çıkan kayıtlar bir 'gözden geçir' kuyruğuna düşer, yüksek güvenli kayıtlar doğrudan muhasebe yazılımına (Logo, Paraşüt, Mikro, Netsis vb.) API veya CSV üzerinden aktarılır

Bu son adım, sistemin gerçekten güvenilir olup olmadığını belirleyen kısım. İyi kurulmuş bir sistem her faturayı '%100 doğru' diye kabul etmez; her alan için bir güven skoru üretir ve düşük skorlu olanları insana havale eder. Amaç insanı tamamen devre dışı bırakmak değil, insanın zamanını yüzlerce rutin faturadan alıp gerçekten dikkat gerektiren birkaç istisnaya yönlendirmek.

##Gerçek bir senaryo: elektronik parça toptancısı

Otuz tedarikçiden ayda ortalama dört yüz fatura alan bir elektronik parça toptancısını düşünelim. Faturaların bir kısmı e-posta ile PDF olarak, bir kısmı kargo ile birlikte gelen kağıt fatura olarak, bir kısmı da tedarikçinin kendi portalından indirilen farklı formatlarda geliyor. Muhasebe ekibi ayın ilk haftasını neredeyse tamamen bu faturaları sisteme girmeye ayırıyor.

Kurulan sistemde faturalar tek bir e-posta adresine ('faturalar@...') veya paylaşımlı bir tarama klasörüne düşüyor. Arka planda OCR + LLM hattı her belgeyi birkaç saniyede işleyip yapılandırılmış bir kayda çeviriyor. Muhasebeci artık tek tek fatura açmıyor; her sabah bir ekranda o günkü işlenmiş faturaların listesini, düşük güvenli olanların üstte vurgulandığı bir tabloyu görüyor. Yüksek güvenli kayıtları toplu onaylayıp muhasebe programına tek tuşla aktarıyor, sadece işaretlenmiş birkaç faturayı elle kontrol ediyor.

Haftalık rutinde değişen şey şu: ayın ilk haftasına yayılan altı-yedi saatlik veri girişi, günde on-on beş dakikalık bir kontrol işine dönüşüyor. Mükerrer fatura girişi neredeyse sıfıra iniyor çünkü sistem aynı fatura numarasını ikinci kez gördüğünde otomatik uyarı veriyor — elle girişte gözden kolayca kaçan bir hata türü.

##Nerede iyi çalışır, nerede zorlanır

Bu teknolojiyi olduğundan daha yetenekli göstermek kolay ama dürüst olmak gerekirse her koşulda aynı doğrulukta çalışmıyor. Temiz taranmış PDF faturalarda doğruluk oranı çok yüksek; telefonla eğik açıdan, kötü ışıkta çekilmiş fotoğraflarda ya da elle yazılmış notlar içeren faturalarda hata oranı belirgin şekilde artıyor.

• ▸El yazısı notlar veya damga/imza üstüne yazılmış rakamlar — düşük doğruluk, mutlaka insan kontrolü gerekir
• ▸Çok satırlı, iç içe indirim/iskonto hesaplı karmaşık faturalar — ekstra doğrulama kuralı yazmak gerekir
• ▸Birden fazla para birimi ve döviz kuru içeren faturalar — kur bilgisi ayrıca doğrulanmalı
• ▸Düşük çözünürlüklü telefon fotoğrafları — ön işleme adımı iyileştirilse bile bazen elle girişten farksız kalır
• ▸Yepyeni bir tedarikçi formatı — ilk birkaç faturada güven skoru düşük çıkabilir, sistem o formata 'alışana' kadar

Bu yüzden 'kur ve unut' bir sistem değil; ilk iki-üç hafta gerçek faturalarla kalibrasyon ister. Güven skoru eşiğini çok gevşek tutarsan hatalı kayıtlar muhasebeye sızar, çok sıkı tutarsan neredeyse her fatura insana düşer ve otomasyonun anlamı kalmaz. Doğru eşiği bulmak, ilk birkaç yüz faturayı gözlemleyip ayarlamakla oluyor.

Aynı hat, tasarımı biraz genişletildiğinde faturayla sınırlı kalmıyor. İrsaliye, makbuz, banka ekstresi ya da tedarikçi sözleşmesi gibi belgeler de benzer bir OCR + LLM adımından geçebilir — tek fark her belge türü için ayrı bir şema tanımlamak (irsaliyede 'teslim tarihi' ve 'sipariş no' önemliyken faturada 'KDV' ve 'ödeme vadesi' öne çıkar). Bu yüzden ilk kurulumda sadece faturayı değil, muhasebe ve operasyon ekibinin elle işlediği tüm tekrarlayan belge türlerini listelemek, aynı altyapıyı ikinci kez kurmadan genişletmeyi kolaylaştırıyor.

##Kurulum ne kadar sürer, maliyeti nasıl hesaplanır?

Hazır bir OCR API'si (Google Cloud Vision, AWS Textract gibi) ve bir LLM çağrısını birleştiren, tek bir muhasebe programına bağlanan çalışır bir ilk sürüm genelde üç-altı haftalık bir geliştirme işi. Bu süreye görüntü ön işleme, şema tasarımı, doğrulama kuralları ve muhasebe yazılımı entegrasyonu dahil. Birden fazla tedarikçi formatını sağlam biçimde kapsamak ve gözden geçirme ekranını kullanışlı hale getirmek işin asıl zamanını alan kısım — 'faturayı okumak' kısmı aslında en kolay parça.

Çalışma zamanı maliyeti ise çoğunlukla API kullanımına göre değişiyor: OCR + LLM çağrısı başına genelde birkaç kuruştan bir-iki liraya kadar bir maliyet çıkıyor, kullanılan modele ve fatura karmaşıklığına göre değişir. Ayda dört yüz fatura işleyen bir işletme için bu, aylık işletme maliyetini genelde birkaç yüz liranın altında tutuyor — elle veri girişine harcanan onlarca saatin maliyetiyle karşılaştırıldığında fark hızla kapanıyor.

##Sık Sorulan Sorular

>Hazır bir SaaS aracı mı kullanmalıyım, yoksa özel mi yaptırmalıyım?

Fatura hacmin düşükse ve standart bir formatta çalışıyorsan hazır bir fatura okuma aracı (birçoğu aylık abonelik modeliyle satılıyor) genelde daha ucuza gelir. Farklı tedarikçi formatları, kendi muhasebe yazılımına özel entegrasyon ihtiyacı ya da fatura dışında sözleşme/irsaliye gibi başka doküman türlerini de aynı hatta işleme isteği varsa, özel bir çözüm zamanla daha esnek ve genelde daha ucuz çıkıyor çünkü abonelik başına ödeme yerine sadece kullandığın API çağrısı kadar ödüyorsun.

>Bu sistem KDV hesaplama hatalarını da yakalar mı?

Doğrudan bir vergi denetimi yapmaz ama basit aritmetik tutarlılık kontrolleri ekleyebilirsin: ara toplam ve KDV tutarının toplamı genel toplamla eşleşiyor mu, KDV oranı beklenen aralıkta mı gibi. Bu, elle girişte gözden kaçan tutarsızlıkları erken yakalayan ucuz bir güvenlik ağı — ama resmi bir vergi danışmanlığının yerini tutmuyor.

>Elle taranmış veya fotoğraflı faturalarla çalışır mı?

Evet ama doğruluk görüntü kalitesine doğrudan bağlı. Düz bir yüzeyde, iyi ışıkta, kırpılmadan çekilmiş bir fotoğraf OCR için genelde yeterli. Eğik açı, gölge veya bulanıklık doğruluğu belirgin şekilde düşürüyor — bu yüzden pratikte kağıt faturaları doğrudan tarayıcıdan geçirmek, telefonla fotoğraflamaktan daha güvenilir sonuç veriyor.

>Muhasebe programıma (Logo, Paraşüt, Mikro) nasıl bağlanır?

Çoğu popüler muhasebe yazılımının bir API'si ya da en azından toplu içe aktarım için kabul ettiği bir CSV/XML formatı var. Sistem yapılandırdığı fatura verisini bu formata çevirip doğrudan API üzerinden gönderir ya da düzenli aralıklarla bir içe aktarım dosyası üretir. API desteği yoksa bile CSV üzerinden yarı otomatik bir köprü kurmak, elle girişten hâlâ çok daha hızlı.

>Bu sistem muhasebecinin işine son mu veriyor?

Hayır, ama işin niteliğini değiştiriyor. Rutin veri girişi ortadan kalkıyor; muhasebecinin zamanı istisnaları kontrol etmeye, nakit akışını yorumlamaya ve vergi/beyanname tarafındaki asıl uzmanlık gerektiren işlere kayıyor. Küçük bir işletmede bu genelde kadro azaltmaktan çok, aynı kişinin ay sonunda faturaya boğulmadan daha stratejik işlere vakit ayırabilmesi anlamına geliyor.

>Yapay zeka modeli kendinden emin ama yanlış bir rakam çıkarabilir mi?

Evet, ve bu OCR + LLM hattının en çok göz ardı edilen riski. Model bazen düşük kaliteli bir görüntüde okuyamadığı bir rakamı 'tahmin ederek' doldurabilir, üstelik bunu yüksek güvenle yapabilir. Bunun tek gerçek çözümü, modelin kendi güven skoruna körü körüne güvenmemek: toplamların tutarlılığını ayrıca aritmetik olarak doğrulamak, aykırı değerleri (örneğin her zamankinden on kat büyük bir tutarı) otomatik işaretlemek ve ilk birkaç ay rastgele seçilmiş bir örneklemi elle çapraz kontrol etmek. Bu ekstra katman, sistemin 'kendinden emin ama yanlış' senaryosuna karşı asıl güvenceyi sağlıyor.

Bu tür doküman okuma sistemlerinin bir de veri gizliliği tarafı var — özellikle müşteri veya tedarikçi bilgisi içeren belgeleri bir yapay zeka servisine gönderirken nelere dikkat etmen gerektiğini KVKK yazımızda ele aldık. Kendi iş akışın için bir fizibilite konuşmak istersen, birkaç soruyla başlayabiliriz.