PDF’den tutarı doğru okumakla doğru muhasebe kaydı oluşturmak aynı iş değildir. Sistem rakamı kusursuz çıkarsa bile yanlış tedarikçiyle eşleştirebilir, iskonto satırını ürün sanabilir veya daha önce işlenmiş belgeyi yeniden aktarabilir. Belge otomasyonunda asıl değer, okunan bilgiyi kontrollü bir işleme dönüştürmektir.
OCR ile fatura işleme, görüntüdeki metni tanıma adımını alan çıkarımı, iş kuralı kontrolü ve hedef sistem aktarımıyla birleştirir. Sağlıklı bir akış her belgeyi zorla tamamlamaz; emin olmadığı kaydı nedenini açıklayarak incelemeye bırakır.
Bazı PDF’lerde seçilebilir metin bulunur; bazıları yalnızca taranmış sayfa görüntüsüdür. Metin içeren belgede doğrudan ayrıştırma kullanılabilirken tarama için OCR gerekebilir. Dosyanın uzantısı tek başına içerik kalitesini söylemez.
Kaynak sistem yapılandırılmış belge verisi sağlıyorsa önce bu seçenek değerlendirilmelidir. Zaten alanlara ayrılmış bilginin görüntüsünü tekrar okumak gereksiz hata alanı oluşturabilir. OCR, yapılandırılmış kaynağın bulunmadığı veya uygun olmadığı durumlarda devreye girebilir.
Belge kabulünde dosya türü, sayfa sayısı, okunabilirlik ve zararlı içerik kontrolleri planlayın. Çalışmayan bir dosyayı sessizce atlamak yerine kaynağını ve reddedilme nedenini kaydedin. Operasyon ekibi hangi belgenin neden işlenmediğini görebilmelidir.
OCR bir sayfadaki kelimeleri bulur. Belge işleme katmanı bu metnin fatura tarihi mi, vade tarihi mi, yoksa sipariş referansı mı olduğuna karar vermeye çalışır. Bir tedarikçinin şablonunda aynı alan farklı yerde bulunabilir.
Alan sözlüğünü proje başında hazırlayın. Belge numarası, tedarikçi kimliği, para birimi, satır tutarı ve toplam gibi alanların veri türünü açıklayın. Kaynakta bulunmayan alan için tahmin yürütülecekse bunun otomatik muhasebe kararına dönüşmemesi gerekir.
{
"document_id": "ornek-belge-104",
"currency": "TRY",
"invoice_total": "12500.00",
"review_required": true,
"review_reason": "Tedarikçi eşleşmesi doğrulanamadı"
}
Bu örnek bir veri sözleşmesidir; çalışır entegrasyon kodu değildir. Sayısal alanların biçimi ve para hassasiyeti hedef ERP’nin beklediği kurallarla belirlenmelidir.
Satır toplamlarıyla genel toplamın uyuşması yararlı bir kontroldür; tek başına belgenin doğru okunduğunu göstermez. Vergi, iskonto, yuvarlama ve farklı para birimi kuralları sonucu etkileyebilir. Kontrol toleransını muhasebe sorumlularıyla tanımlayın.
Mükerrer belge kontrolünde sadece dosya adına güvenmeyin. Aynı içerik farklı adla gönderilebilir, aynı ad farklı belgelerde kullanılabilir. Kaynak kimliği, belge numarası ve tedarikçi ilişkisi gibi iş kuralları birlikte düşünülmelidir.
İnceleme ekranında kullanıcıya yalnızca çıkarılmış tabloyu sunmak yeterli olmayabilir. Tutarın veya tarihin belgenin hangi bölümünden okunduğunu göstermek düzeltmeyi kolaylaştırır. Değiştirilen değer ve değişikliği yapan kişi kaydedilmelidir.
Güven puanı varsa bunu otomatik doğruluk yüzdesi gibi sunmayın. Eşikler, işletmenizin belge örnekleri üzerinde değerlendirilmelidir. Kritik bir toplam alanı için gereken kontrol, açıklama metninden farklı olabilir. Belgeler arasında aynı puanın aynı hata riskini taşıdığı varsayılmamalıdır.
İlk aşamada bütün belgeleri onay kuyruğuna almak makul olabilir. Sonraki otomatik geçiş kararları, gerçek düzeltme kayıtları incelenerek alan ve belge türü bazında verilmelidir. Pilot sürecin amacı yalnızca hız görmek değil, hangi hataların oluştuğunu anlamaktır.
“Okundu”, “doğrulandı”, “onaylandı” ve “ERP’ye kaydedildi” farklı durumlardır. Hedef sistem geçici olarak yanıt vermezse belgeyi yeniden okumak yerine aktarım adımı kontrollü biçimde tekrar denenebilmelidir. Aynı belge için ikinci kayıt açılmaması gerekir.
Excel ve e-posta otomasyonu rehberi, belgeyi iş akışına alacağınız kanalı planlamaya yardımcı olur. API entegrasyonu örnekleri ise hedef sisteme bağlantının kapsamını açıklığa kavuşturabilir.
Örnek pilotta farklı tedarikçilerden temiz PDF, eğik tarama, çok sayfalı belge ve yeniden gönderilmiş kopya seçin. Her birinde alan bazlı hata, inceleme süresi ve aktarım sonucunu kaydedin. Yalnızca toplam işlenen dosya sayısına bakmak sorunlu belgeleri görünmez bırakır.
Hayır. Tarama kalitesi, belge düzeni, yazı tipi, tablo yapısı ve görüntü bozulmaları sonucu etkileyebilir. Metnin doğru okunması da alanın doğru yorumlandığını garanti etmez. Bu nedenle tutar ve kimlik doğrulaması, mükerrer belge kontrolü ve inceleme kuyruğu gerekir. Pilot çalışmada farklı belge türleri kullanılmalı; hata oranı yalnızca dosya bazında değil, kritik alanlar bazında da izlenmelidir.
Her zaman gerekmez. Seçilebilir metin veya yapılandırılmış kaynak veri varsa önce doğrudan ayrıştırma değerlendirilmelidir. Yine de metnin belge alanlarına doğru eşlenmesi ve hedef sistem kurallarına uygunluğu kontrol edilmelidir. OCR gereksinimini dosya uzantısıyla belirlemek yerine örnek belgelerin iç yapısını inceleyin. Farklı kaynaklardan gelen belgeler için aynı akış içinde farklı okuma yöntemleri kullanılabilir.
Bu karar doğrulama sonuçlarına ve işletmenin onay politikasına bağlıdır. Başlangıçta kontrollü inceleme kullanmak, belge türlerine göre hataları görmeyi sağlar. Belirlenen şartları sağlayan kayıtlar daha sonra otomatik aktarılabilir. Kaydetme sırasında tekrar işlemeyi önleyen kimlikler, açık durum bilgisi ve hata kaydı bulunmalıdır. Belgenin okunmuş olması, mali kaydın doğru ve yetkili olduğu anlamına gelmez.
Gerçek müşteri bilgilerini paylaşmadan örnek belge seti hazırlayın. Her örneğin beklenen alanlarını muhasebe ekibi doğrulasın. Okunabilir dosyaların yanında başarısız olması beklenen belgeleri de ekleyin; sistemin bu dosyaları doğru şekilde durdurması da başarıdır.
ARKTECH otomasyon hizmetleri için talebinizi belge hacmi, kaynak türü ve hedef ERP bilgisiyle iletin. Önce hangi alanın hangi koşulda insan onayı gerektireceğini kararlaştırın.
Teknik başvuru: Microsoft Learn: Document Intelligence.
