@hakanoztrkTürkçe belge okuma 2026: fatura, irsaliye ve el yazısı formlarda hangi yöntem nerede çalışıyor
Muhasebe ofislerine yazılım satıyoruz, belge okuma bizim işimizin merkezinde. Bir yılda üç farklı yaklaşım denedik ve Türkçe belgelerde durumun İngilizceden epey farklı olduğunu gördük. Not defterimi açıyorum.
Belge tiplerimiz üç grupta: dijital doğan e-fatura ve e-arşiv belgeleri, taranmış kağıt faturalar, bir de elle doldurulmuş formlar.
Dijital belgelerde yapay zekaya hiç gerek yok. Bunlar zaten yapılandırılmış veri taşıyor, doğrudan okunuyor. Burada model kullanmak hem para hem de hata demek. Şaşırtıcı biçimde pek çok ekip bu ayrımı yapmadan her şeyi modele veriyor. İlk işiniz, belgenin hangi gruba girdiğini anlayan bir yönlendirme adımı yazmak olsun.
Taranmış faturalarda iki aşamalı çalışıyoruz. Önce klasik bir metin tanıma motoru, sonra çıkan metni modele verip alanları çıkarma. Türkçe karakterler burada ilk büyük engel. Özellikle İ, ı, ş, ğ ayrımında eski motorlar zayıf. Dil paketini Türkçe olarak yüklemek ve tarama çözünürlüğünü yükseltmek, model tarafında yaptığımız bütün iyileştirmelerden daha fazla fayda sağladı. 300 dpi altındaki taramalarda hiçbir yöntem kurtarmıyor, kaynağa müdahale edin.
İkinci engel: damga ve kaşe. Kaşenin üstüne denk gelen rakamlar okunmuyor. Bunu çözemedik, bu tip belgeler insan kuyruğuna gidiyor ve oran yüzde 6 civarında.
Üçüncü engel: tutar biçimleri. Türkçe belgede binlik ayırıcı nokta, ondalık ayırıcı virgül. Model bazen bunu tersine çeviriyor ve 1.250,00 lirayı 1250.00 yerine 1,250 olarak anlıyor. Çözümümüz, tutar alanlarını model çıktısından aldıktan sonra kural tabanlı bir düzeltmeden geçirmek ve KDV tutarıyla toplam arasındaki tutarlılığı kontrol etmek oldu. Tutarsızsa kayıt insana gidiyor. Bu tek kontrol, yakaladığımız hataların yarısını buluyor.
Dördüncü engel: tarih biçimleri. Gün ay yıl sırası Türkçe belgede standart ama bazı yabancı menşeli belgelerde ay gün yıl geliyor. 03/04/2026 iki şekilde de okunabiliyor. Biz belgenin menşeini de bir alan olarak çıkarıp tarih yorumunu ona bağladık.
El yazısı formlar en zor kısım. Burada doğrudan belgeyi görsel olarak anlayan modeller klasik metin tanımadan belirgin biçimde iyi. Buna karşılık güven skoru düşük ve hata yaptığında sessiz hata yapıyor, yani okunaklı ama yanlış bir sonuç üretiyor. Bu yüzden el yazısı formlarda tam otomasyon yapmıyoruz; model alanları dolduruyor, insan onaylıyor. Böyle kullanınca işlem süresi kişi başına ciddi biçimde kısaldı, ama onay adımını kaldırmayı düşünmüyoruz.
Son bir pratik not: hangi yöntemi kullanırsanız kullanın, okunan alanla belgenin görüntüsünü yan yana gösteren bir onay ekranı yapın. Kullanıcı bir alana tıkladığında belgedeki ilgili yeri işaretleyin. Bu arayüz, doğruluk oranını artırmıyor ama kullanıcının hatayı bulma hızını kat kat artırıyor.
Türkçe belgelerle uğraşan var mı, kaşe ve damga sorununa çözüm bulan oldu mu?
Belge tiplerimiz üç grupta: dijital doğan e-fatura ve e-arşiv belgeleri, taranmış kağıt faturalar, bir de elle doldurulmuş formlar.
Dijital belgelerde yapay zekaya hiç gerek yok. Bunlar zaten yapılandırılmış veri taşıyor, doğrudan okunuyor. Burada model kullanmak hem para hem de hata demek. Şaşırtıcı biçimde pek çok ekip bu ayrımı yapmadan her şeyi modele veriyor. İlk işiniz, belgenin hangi gruba girdiğini anlayan bir yönlendirme adımı yazmak olsun.
Taranmış faturalarda iki aşamalı çalışıyoruz. Önce klasik bir metin tanıma motoru, sonra çıkan metni modele verip alanları çıkarma. Türkçe karakterler burada ilk büyük engel. Özellikle İ, ı, ş, ğ ayrımında eski motorlar zayıf. Dil paketini Türkçe olarak yüklemek ve tarama çözünürlüğünü yükseltmek, model tarafında yaptığımız bütün iyileştirmelerden daha fazla fayda sağladı. 300 dpi altındaki taramalarda hiçbir yöntem kurtarmıyor, kaynağa müdahale edin.
İkinci engel: damga ve kaşe. Kaşenin üstüne denk gelen rakamlar okunmuyor. Bunu çözemedik, bu tip belgeler insan kuyruğuna gidiyor ve oran yüzde 6 civarında.
Üçüncü engel: tutar biçimleri. Türkçe belgede binlik ayırıcı nokta, ondalık ayırıcı virgül. Model bazen bunu tersine çeviriyor ve 1.250,00 lirayı 1250.00 yerine 1,250 olarak anlıyor. Çözümümüz, tutar alanlarını model çıktısından aldıktan sonra kural tabanlı bir düzeltmeden geçirmek ve KDV tutarıyla toplam arasındaki tutarlılığı kontrol etmek oldu. Tutarsızsa kayıt insana gidiyor. Bu tek kontrol, yakaladığımız hataların yarısını buluyor.
Dördüncü engel: tarih biçimleri. Gün ay yıl sırası Türkçe belgede standart ama bazı yabancı menşeli belgelerde ay gün yıl geliyor. 03/04/2026 iki şekilde de okunabiliyor. Biz belgenin menşeini de bir alan olarak çıkarıp tarih yorumunu ona bağladık.
El yazısı formlar en zor kısım. Burada doğrudan belgeyi görsel olarak anlayan modeller klasik metin tanımadan belirgin biçimde iyi. Buna karşılık güven skoru düşük ve hata yaptığında sessiz hata yapıyor, yani okunaklı ama yanlış bir sonuç üretiyor. Bu yüzden el yazısı formlarda tam otomasyon yapmıyoruz; model alanları dolduruyor, insan onaylıyor. Böyle kullanınca işlem süresi kişi başına ciddi biçimde kısaldı, ama onay adımını kaldırmayı düşünmüyoruz.
Son bir pratik not: hangi yöntemi kullanırsanız kullanın, okunan alanla belgenin görüntüsünü yan yana gösteren bir onay ekranı yapın. Kullanıcı bir alana tıkladığında belgedeki ilgili yeri işaretleyin. Bu arayüz, doğruluk oranını artırmıyor ama kullanıcının hatayı bulma hızını kat kat artırıyor.
Türkçe belgelerle uğraşan var mı, kaşe ve damga sorununa çözüm bulan oldu mu?
12 6 yorum
