Şirketlerde belge trafiği hiç bitmiyor. Fatura geliyor, irsaliye ekleniyor, müşteri formu açılıyor, sözleşme revize ediliyor. Her biri farklı şablonda, farklı tedarikçiden; kimi zaman PDF, kimi zaman taranmış görsel olarak geliyor. Asıl yük ise belgeyi açıp doğru alanları bulmak, ERP ya da CRM’e işlemek, eksikleri kontrol etmek ve onay akışına dahil etmek. İşte tam bu noktada yapay zeka doküman okuma devreye giriyor.
Bu yaklaşım, belgedeki metni yalnızca “okumakla” yetinmez; alanları tanır, bağlamı yorumlar ve yapılandırılmış veriye dönüştürür. Örneğin bir faturada vergi numarası, fatura tarihi, toplam tutar ve kalem satırları ayrı ayrı çıkarılabilir. Bir sözleşmede başlangıç tarihi, taraf unvanları, fesih maddesi ya da ödeme koşulları etiketlenebilir. Hedef açıktır: manuel veri girişini azaltmak, işlem süresini dakikalardan saniyelere çekmek ve hata oranını kontrol altında tutmak.
Teknik tarafta ise süreç tek katmanlı değildir. OCR, belge sınıflandırma, alan çıkarma, doğrulama kuralları, insan onayı ve sistem entegrasyonu birlikte çalışır. Sağlam bir kurgu kurulmadığında, “belgeyi okuyor” gibi görünen sistem üretimde güven vermez. Kurumsal ölçekte başarılı sonuç, model kadar iş akışı tasarımına da bağlıdır.
Yapay zeka doküman okuma tam olarak nedir?
Klasik OCR, bir görseldeki yazıyı metne çevirir. Bu önemli bir adımdır ama tek başına yeterli değildir. Çünkü işletmelerin ihtiyacı ham metin değil, kullanılabilir veridir. Yapay zeka destekli doküman okuma ise OCR çıktısını belge düzeni ve içerik bağlamıyla birleştirir. Sistem, “12.04.2025” ifadesinin sayfa üzerindeki konumuna, etrafındaki başlıklara ve diğer alanlarla ilişkisine bakarak bunun teslim tarihi mi, fatura tarihi mi, sözleşme başlangıcı mı olduğunu ayırt etmeye çalışır.
Bir örnek düşünelim. Aynı gün içinde 200 fatura işlendiğini varsayın. Tedarikçilerden biri e-Fatura PDF’i gönderir, diğeri taranmış kağıt fatura yollar, bir başkası ise İngilizce format kullanır. Klasik kural tabanlı sistem, sabit alan yerleşimi değiştiğinde zorlanır. Yapay zeka destekli yaklaşım ise farklı şablonlardan öğrenerek daha esnek davranır. Yine de yüzde 100 otomasyon her belge tipi için gerçekçi değildir. Kritik alanlarda güven skoru düşükse insan onayı gerekir.
Temel bileşenler
- OCR katmanı: PDF, JPEG veya PNG içindeki metni çıkarır.
- Belge sınıflandırma: Belgenin fatura mı, irsaliye mi, başvuru formu mu olduğunu belirler.
- Alan çıkarma: Tarih, tutar, vergi numarası, müşteri adı, satır kalemleri gibi verileri etiketler.
- Doğrulama: KDV toplamı, para birimi, zorunlu alanlar, format kontrolleri uygulanır.
- İnsan onayı: Güven skoru örneğin 0.80 altındaysa operatör ekranı açılır.
- Entegrasyon: ERP, CRM, muhasebe, arşiv ve iş akışı sistemlerine kayıt atılır.
Fatura, irsaliye, sözleşme ve formlarda süreç nasıl işler?
İhtiyaçlar belge türüne göre değişir. Faturada sayısal doğruluk öne çıkar. İrsaliyede sevk tarihi, teslim alan ve ürün satırları önemlidir. Sözleşmede ise serbest metin içindeki maddelerin anlamı daha belirleyicidir. Formlarda el yazısı, checkbox ve eksik alan problemi sık görülür. Her şeyi tek bir modelle çözmeye çalışmak yerine, belge bazlı akış tasarlamak daha sağlıklı olur.
Pratik bir senaryo üzerinden gidelim. Bir işletme günde ortalama 350 belge alıyor olsun: 180 fatura, 90 irsaliye, 50 müşteri formu, 30 sözleşme eki. Her belge için 2 ila 6 dakika manuel işlem yapıldığında günlük ciddi bir operasyon yükü oluşur. Yapay zeka destekli bir akışta sistem belgeleri gelen kutusundan alır, sınıflandırır, alanları çıkarır, doğrular ve yalnızca istisnaları kullanıcıya yönlendirir. Kazanç sadece hızla sınırlı değildir; aynı zamanda standartlaşma da sağlanır.
Fatura işleme akışı
- E-posta, portal ya da tarayıcıdan belge alınır.
- PDF metin tabanlıysa doğrudan parse edilir; taranmışsa OCR uygulanır.
- Fatura no, tarih, VKN/TCKN, para birimi, ara toplam, KDV ve genel toplam çıkarılır.
- Kalem satırları tablo yapısından okunur.
- Toplam kontrolü yapılır: satır toplamı + vergi = genel toplam.
- Sonuç ERP’ye JSON veya API ile aktarılır.
Örneğin aşağıdaki gibi bir çıktı üretilir:
{
"document_type": "invoice",
"invoice_no": "INV-2025-0412",
"invoice_date": "2025-04-12",
"tax_id": "1234567890",
"currency": "TRY",
"total_amount": 18450.75,
"confidence": 0.93
}Sözleşme ve form işlemede fark nerede?
Sözleşmelerde yapı daha serbesttir. Aynı madde bir belgede “ödeme planı”, diğerinde “ücretlendirme” başlığı altında yer alabilir. Bu noktada yalnızca OCR yeterli olmaz; doğal dil işleme ve varlık tanıma katmanları gerekir. Amaç her cümleyi özetlemek değil, iş için kritik alanları bulmaktır. Taraf bilgileri, yürürlük tarihi, yenileme süresi, ceza koşulu gibi veriler önceliklendirilir.
Form tarafında ise checkbox, imza alanı, kimlik bilgisi ve el yazısı sorun yaratır. El yazısı tanıma, matbu metne kıyasla daha değişken sonuçlar verir. Bu nedenle form süreçlerinde operatör doğrulama ekranı neredeyse her zaman tasarıma dahil edilir. Başarılı projelerde amaç insanı tamamen devreden çıkarmak değil, yalnızca gerekli olduğu yerde devreye girmesini sağlamaktır.
Doğruluk oranını ne belirler?
En kritik soru genellikle budur: “Ne kadar doğru çalışır?” Buna tek bir oranla yanıt vermek yanıltıcı olabilir. Çünkü performans; belge kalitesi, dil, şablon çeşitliliği, tablo karmaşıklığı, el yazısı oranı ve eğitim verisinin kalitesiyle değişir. 300 DPI taranmış, net ve standart bir faturada alınan sonuçla; cep telefonu ile eğik çekilmiş, kırışık bir irsaliyede alınan sonuç aynı olmaz.
Üretim ortamında doğruluğu alan bazında takip etmek gerekir. Genel belge doğruluğu yerine şu metrikler daha anlamlıdır: fatura no doğruluğu, toplam tutar doğruluğu, satır kalemi çıkarma başarısı, belge sınıflandırma başarısı, düşük güven skorlu belge oranı. Örneğin toplam tutar alanı yüzde 98 doğruyken satır kalemleri yüzde 82’de kalabilir. Bu fark, tasarımı doğrudan etkiler.
Kaliteyi yükselten pratik adımlar
- Taranmış belgelerde en az 200-300 DPI kalite hedeflemek.
- Belge türlerini ilk günden ayırmak; tek havuz yaklaşımından kaçınmak.
- 10 yerine 1.000 belgeyle pilot yapmak. Küçük örneklem yanıltır.
- Doğrulama kurallarını iş kurallarıyla desteklemek. Tarih gelecekte olamaz, KDV oranı beklenen aralıkta olmalı gibi.
- İstisna ekranında kullanıcı düzeltmelerini modele geri beslemek.
Burada önemli bir ayrım var: “Model eğitimi” tek başına çözüm değildir. Düşük kaliteli belge kaynağı düzeltilmeden, entegrasyon katmanı sağlam kurulmadan ve onay akışları tanımlanmadan sürdürülebilir başarı gelmez.
Manuel işi azaltmanın gerçekçi yöntemleri
Manuel yükü azaltmak için ilk hedef, her belgeyi tam otomatik işlemek olmak zorunda değildir. Daha etkili yaklaşım, operasyonu parçalara ayırmaktır. En çok zamanı hangi adım alıyor? Veri girişi mi, belge ayırma mı, mutabakat mı, eksik alan takibi mi? Pek çok kurumda asıl kayıp, veri girişinden çok istisna yönetiminde ortaya çıkar.
Bu yüzden projeyi 2 aşamada ele almak işe yarar. İlk aşamada yüksek hacimli ve nispeten standart belgeler seçilir. Fatura ve başvuru formları bunun için uygundur. İkinci aşamada sözleşme ekleri ya da serbest formatlı belgeler devreye alınır. Böylece ekip, ilk 6-8 haftada ölçülebilir sonuç görür; ardından daha karmaşık sürece geçer.
Uygulanabilir otomasyon desenleri
- Confidence-based routing: Güven skoru 0.90 üstüyse otomatik kaydet, altındaysa operatöre gönder.
- Human-in-the-loop: Sadece kritik alanları kullanıcıya göster. Tüm belgeyi yeniden girdirtme.
- Template fallback: Belirli tedarikçiler için sabit şablon kuralı, geri kalanlar için AI modeli kullan.
- Duplicate control: Aynı fatura no + tutar + tarih kombinasyonunda mükerrer kayıt uyarısı ver.
- API-first entegrasyon: Çıkarılan veriyi e-posta ekinde değil, doğrudan ERP/CRM API’sine aktar.
Manuel işi azaltan asıl nokta, tek ekran deneyimidir. Kullanıcı belgeyi bir yerde açıp veriyi başka bir yerde girmemelidir. Belge görüntüsü solda, çıkarılan alanlar sağda; hata ve uyarılar ise net biçimde aynı ekranda yer almalıdır. 15 alan için sekmeler arasında dolaşmak, otomasyon kazanımını geri alır.
Entegrasyon, güvenlik ve KVKK tarafı neden kritik?
Belgeler çoğu zaman hassas veri içerir. Kimlik bilgileri, imzalar, fiyatlandırma, banka hesapları, ticari şartlar. Bu nedenle çözümün yalnızca modeli değil, işletim biçimi de dikkatle tasarlanmalıdır. Türkiye’de faaliyet gösteren şirketler için KVKK kapsamı açıktır; verinin nerede işlendiği, kimlerin eriştiği, ne kadar süre saklandığı ve logların nasıl tutulduğu önem taşır.
Kurumsal projelerde sık görülen mimari seçenekler şunlardır: bulut tabanlı servis, özel VPC, hibrit kurulum veya on-premise bileşenler. Seçim; belge hacmine, regülasyona ve mevcut sistem mimarisine göre yapılır. Örneğin günde 5.000 belge işleyen bir yapıda kuyruk yönetimi, asenkron işleme ve yeniden deneme mekanizmaları planlanmalıdır. Aksi durumda entegrasyon darboğazı yaşanır.
Kontrol listesi
- Rol bazlı erişim ve audit log tutuluyor mu?
- Ham belge ile çıkarılan veri ayrı katmanlarda saklanıyor mu?
- API çağrıları kimlik doğrulama ve oran sınırlama ile korunuyor mu?
- Yanlış eşleşme durumunda geri alma veya yeniden işleme mekanizması var mı?
- Maskeleme gereken alanlar tanımlandı mı?
Başarılı bir proje, belgeyi okuyup veri çıkarmakla tamamlanmaz. İş sonucu üretmesi gerekir. Veri, doğru sisteme, doğru formatta ve izlenebilir şekilde akmalıdır.
Proje başlangıcında hangi kapsam daha mantıklı?
En güvenli başlangıç, 1 belge tipi ve 1 iş kuralı setiyle pilot yapmaktır. Örneğin son 3 aya ait 1.000 fatura toplanır, alan listesi netleştirilir, başarı kriteri tanımlanır. “Tüm belgelerde maksimum otomasyon” gibi geniş hedefler yerine, “fatura tarihi, toplam tutar ve tedarikçi unvanında ölçülebilir doğruluk” gibi somut bir kapsam seçilmelidir.
Pilot sonrasında şu sorular netleşir: Hangi alanlar yüksek güvenle çıkarılıyor? Operatör en çok hangi alanı düzeltiyor? Hangi tedarikçi formatları sorun çıkarıyor? İkinci faz işte bu verilerle planlanır. Bu şekilde ilerleyen projelerde yatırım kararı da daha sağlam veriye dayanır.
Yapay zeka doküman okuma, doğru kurgulandığında belge operasyonlarını hızlandırır, veri kalitesini artırır ve ekiplerin tekrar eden işleri azaltmasına yardımcı olur. En iyi sonuç ise teknoloji, iş kuralı ve kullanıcı deneyimi birlikte tasarlandığında ortaya çıkar.