Fatura, Sözleşme ve Formlarda Belge İşleme Otomasyonu

Belge işleme otomasyonu nedir, hangi işi devralır?

Belge işleme otomasyonu; fatura, sözleşme ve form gibi belgelerden gereken bilgileri okuyan, bu bilgileri kurallarla doğrulayan ve sonucu ERP, muhasebe ya da belge yönetim sistemine yazan bir hattır. Yapay zeka bu hattın yalnızca bir adımıdır. Çoğu projede başarıyı modelden çok belgelerin nereden geldiği, doğrulama kuralları ve belirsiz kayıtların kime düştüğü belirler. Tipik bir hat beş adımdan oluşur:

1. Alma: Belgeleri e-postadan, tarayıcıdan, portaldan, e-fatura entegratöründen ya da paylaşılan klasörden toplamak ve aynı belgenin iki kez girmesini engellemek.
2. Sınıflandırma: Belgenin türünü (fatura, irsaliye, sözleşme, başvuru formu) ve gerekirse tedarikçisini ya da şablonunu belirlemek.
3. Çıkarma: Gereken alanları ve tabloları okumak, her değerin belgede nereden geldiğini kaydetmek.
4. Doğrulama: Değerleri biçim, hesap, ana veri ve iş kurallarıyla kontrol etmek.
5. İnceleme ve aktarım: Kontrollerden geçenleri hedef sisteme yazmak, geçemeyenleri gerekçesiyle bir kişinin önüne getirmek.

Otomasyonun devralmayacağı iş de baştan yazılmalıdır. Ödeme onayı, bir sözleşme maddesinin hukuki değerlendirmesi ya da bir başvurunun kabulü yetkili kişide kalır; hat, bu kişilere doğrulanmış veriyi daha hızlı ve kaynağıyla birlikte getirir.

E-fatura okumak için yapay zeka gerekir mi?

Genellikle hayır: e-fatura zaten yapılandırılmış bir veri dosyasıdır ve doğru yol, görüntüsünü tanımaya çalışmak değil, dosyanın kendisini okumaktır. Gelir İdaresi Başkanlığı'nın e-Fatura sayfasına göre e-Fatura, 5 Mart 2010'dan beri uygulamada olan, veri formatı ve standardı Başkanlık tarafından belirlenen ve XML tabanlı UBL-TR standardını kullanan elektronik bir belgedir. e-Fatura uygulamasına kayıtlı mükelleflerin birbirlerine düzenledikleri faturaları e-Fatura olarak göndermeleri ve almaları zorunludur; kayıtlı olmayanlara ise kâğıt ya da e-Arşiv fatura düzenlenir.

Bu yüzden gelen faturalar tek tip değildir. Aynı muhasebe biriminde e-faturaların XML dosyaları, e-postayla gelen e-Arşiv faturalar, kâğıttan taranmış faturalar ve yurt dışı tedarikçilerin PDF'leri bir arada bulunabilir. Projeye başlamadan önce son birkaç ayın faturalarını bu kanallara göre sayın. Otomasyonun en ucuz kısmı XML'i doğrudan okumaktır, en pahalı kısmı taranmış ve el yazısı içeren belgelerdir. Sık görülen bir hata, e-faturanın PDF görüntüsünü OCR'a sokmaktır; bu, kesin olan veriyi tahmine çevirir. XML dosyasına entegratörünüzden, e-Fatura portalından ya da ERP'nizin e-belge modülünden ulaşıp ulaşamadığınızı kontrol edin.

Faturadan hangi alanların çıkarılacağına karar verirken başlangıç noktası mevzuattır. Vergi Usul Kanunu'nun 230. maddesi bir faturada en az bulunması gereken bilgileri sayar: düzenlenme tarihi, seri ve sıra numarası; düzenleyenin ve müşterinin adı, unvanı, adresi, vergi dairesi ve hesap numarası; malın veya işin cinsi, miktarı, fiyatı ve tutarı; satılan malların teslim tarihi ve irsaliye numarası. Bu liste hem çıkarma şemanızın iskeleti hem de "zorunlu bir alan eksik mi?" kontrolünün dayanağıdır.

OCR, yerleşim modeli ve dil modeli arasındaki fark nedir?

OCR metni okur, yerleşim (layout) modeli metnin sayfadaki yerini ve yapısını anlar, dil modeli ise serbest metinden anlam çıkarır; çoğu belge işleme hattı bunları birlikte kullanır.

Yaklaşım	Ne yapar?	Güçlü olduğu yer	Zayıf olduğu yer
Klasik OCR ve şablon kuralları	Görüntüdeki karakterleri metne çevirir; alanları sabit konum veya etiket kurallarıyla bulur	Şablonu değişmeyen formlar, az sayıda tedarikçi	Yeni düzen, eğik tarama, tablolar; her yeni şablon için kural yazmak gerekir
Yerleşim modelleri ve hazır belge modelleri	Metni, konumunu ve sayfa görüntüsünü birlikte değerlendirir; anahtar-değer çiftlerini ve tabloları çıkarır	Düzeni tedarikçiden tedarikçiye değişen faturalar, fişler, formlar	Eğitim verisi veya ilgili belge türü için dil desteği gerekir; serbest metnin anlamını yorumlamaz
Dil modeli veya görsel dil modeliyle şemaya göre çıkarma	Metni ya da görüntüyü okuyup istenen alanları bir şemaya göre doldurur	Sözleşme ve yazışma gibi serbest metin, beklenmeyen biçimler	Belgede olmayan değeri üretebilir; değerin belgede nereden geldiği ayrıca doğrulanmalıdır

LayoutLMv3 gibi yerleşim modelleri metni, konumu ve sayfa görüntüsünü birlikte öğrenir; makalesi form ve fiş anlamayı, belge yerleşim analizini bu modelin hedeflediği görevler arasında sayar. Bulut sağlayıcılarının hazır fatura modelleri de bu aileye girer. Yine de dil desteğini her belge türü için ayrı kontrol edin. Örneğin Microsoft'un Azure Document Intelligence servisinin dil desteği sayfası, hazır fatura modeli için Türkçeyi ve Türk lirasını listelerken hazır sözleşme modeli için yalnızca ABD İngilizcesini listeler. Bir ürünün "Türkçe destekler" demesi, ihtiyacınız olan belge türünde de desteklediği anlamına gelmez.

OCR'a dayalı hatların zayıf noktasını Donut makalesi açıkça sayar: OCR'ın hesaplama maliyeti, dil ve belge türüne göre esnek olmaması ve OCR hatasının sonraki adımlara taşınması. Sonuncusu pratikte en önemlisidir: OCR bir "8"i "B" okursa, sonraki model doğru alanı bulsa bile yanlış değeri yazar. Bu yüzden ölçümü yalnızca son çıktıda değil, OCR adımında da yapın.

Dil modeliyle çıkarma esnektir ama farklı bir risk taşır. OpenAI'ın yapılandırılmış çıktı belgesi, modelin verilen şemaya her zaman uymaya çalışacağını, girdi şemayla ilgisizse bunun halüsinasyona yol açabileceğini ve yapılandırılmış çıktının yine de hata içerebileceğini açıkça yazar. Şema biçimi garanti eder, doğruluğu değil: belgede olmayan bir vergi numarası, şemada zorunlu alan olduğu için uydurulabilir. Çözüm, her alana "bulunamadı" değeri alabilme imkânı tanımak, her değer için belgedeki kaynağı (sayfa ve metin parçası) istemek ve değeri bu kaynakla karşılaştırmaktır.

Hangi belge türüne hangi yaklaşım uyar?

Yaklaşımı belgenin ne kadar yapılandırılmış olduğuna ve hatanın maliyetine göre seçin. Aşağıdaki tablo, belge türüne göre bir başlangıç noktası verir:

Belge türü	Önerilen yaklaşım	Zorunlu doğrulama	İnsan incelemesi ne zaman?
e-Fatura ve XML'i alınabilen e-Arşiv fatura	XML okuyucu; model gerekmez	Ana veri, mükerrerlik, sipariş ve irsaliye eşleşmesi	Yalnızca iş kuralı uyuşmazlığında
PDF veya taranmış fatura (yurt içi, yurt dışı)	OCR ve yerleşim modeli ya da hazır fatura modeli	Vergi numarası biçimi, toplam ve KDV hesabı, sipariş eşleşmesi	Eşiğin altındaki alan, tutmayan toplam, yeni tedarikçi
Sabit şablonlu form	OCR, şablon kuralları, onay kutusu tespiti	Zorunlu alan, kimlik numarası biçimi, tarih aralığı	El yazısı alan, boş zorunlu alan
Serbest düzenli yazışma ve dilekçe	Sınıflandırma ve dil modeliyle alan çıkarma	Kaynak metin parçası, izin verilen değer listesi	Sınıflandırma belirsizse
Sözleşme	Dil modeliyle soru-cevap veya alan çıkarma; her cevapla kaynak paragraf	Kaynağın cevabı desteklemesi, ek ve değişikliklerin hesaba katılması	Sonuç hukuki değerlendirmeye girecekse her zaman

Sözleşmelerde otomasyon neyi yapabilir, neyi yapmamalı?

Sözleşmede otomasyon taraflar, tarihler, süre, yenileme, fesih bildirimi, cezai şart ve uygulanacak hukuk gibi bilgileri bulup kaynağıyla gösterebilir; maddenin hukuki anlamına ise avukat karar verir. Sözleşme bir form değildir. Aynı bilgi farklı maddelere dağılmış olabilir, ek bir protokol maddeyi değiştirmiş olabilir, tanımlar bölümündeki bir terim sözleşmenin tamamının okunuşunu belirleyebilir. Bu yüzden sözleşmede doğru çıktı tek bir değer değil, "cevap ve dayandığı paragraf"tır. Şirket satın almalarındaki hukuki durum tespiti çalışmaları bunun tipik örneğidir: onlarca, bazen yüzlerce sözleşmede aynı sorular sorulur. Devir kısıtı var mı, kontrol değişikliğinde fesih hakkı doğuyor mu, rekabet yasağı ne kadar sürüyor?

Hatson Tech'in durum tespiti (due diligence) ve sözleşme inceleme için kendi geliştirdiği LegalTech ürünü Caseon bu yaklaşımın bir örneğidir. Sözleşme hazırlama ve raporlamayı da aynı çalışma alanında toplar; her cevap dayandığı belge alıntısıyla gösterilir, kaynakları inceleyen ve işi onaylayan avukattır. Ürün hâlâ geliştirme aşamasındadır; nasıl çalıştığını Caseon vaka çalışmamızda anlattık.

Formlarda nelere dikkat etmeli?

Formlarda asıl zorluk el yazısı, onay kutuları, imzalar ve formun taşıdığı kişisel verilerdir. Sabit şablonlu formlarda klasik OCR ve alan konumuna dayalı kurallar çoğu zaman yeterlidir; asıl iş, formun eski ve yeni sürümlerini ayırmak ve onay kutusunun işaretli olup olmadığını güvenilir biçimde tespit etmektir. El yazısı alanlarda başarıyı mutlaka kendi örneklerinizle ölçün ve bu alanlar için inceleme oranını baştan yüksek planlayın. İmzanın varlığını tespit etmek mümkündür; imzanın kime ait olduğunu doğrulamak ise ayrı bir iştir.

Başvuru ve personel formları çoğu zaman kişisel veri, bazen de sağlık gibi özel nitelikli veri içerir. Belgeleri bir bulut servisine gönderecekseniz 6698 sayılı KVKK'nın 9. maddesindeki yurt dışına aktarım şartlarını ve 12. maddedeki veri güvenliği yükümlülüklerini değerlendirin. 12. madde, veri sorumlusunu kendi adına veri işleyenle birlikte güvenlik tedbirlerinden müştereken sorumlu tutar. Yalnızca gereken alanları çıkarın, görüntüleri ve ara çıktıları saklama süresi dolunca silin, inceleme ekranında kişisel verileri yalnızca yetkili kişilere gösterin.

Çıkarılan veri nasıl doğrulanır?

Modelin güven puanına tek başına güvenmeyin; çıkarılan her değeri biçim, hesap, ana veri ve iş kurallarıyla ayrıca kontrol edin.

• Biçim: Vergi kimlik numarası 10, T.C. kimlik numarası 11 haneli mi; tarih geçerli mi; para birimi tanımlı mı?
• Hesap: Satır tutarı miktar çarpı birim fiyatla, ara toplam satırların toplamıyla, KDV tutarı matrah ve oranla, genel toplam ara toplam ve vergilerle tutuyor mu?
• Ana veri: Tedarikçi ERP'de kayıtlı mı; vergi numarası ve IBAN kayıtlı bilgilerle aynı mı?
• Belgeler arası: Fatura, satın alma siparişi ve mal kabul kaydı miktar ve fiyat bazında eşleşiyor mu?
• Mükerrerlik: Aynı tedarikçiden aynı seri ve sıra numarasıyla daha önce fatura girilmiş mi?
• İş kuralları: Tutar onay sınırını aşıyor mu, vade sözleşmeyle uyumlu mu, tedarikçi yeni mi?

Güven puanları yine de işe yarar, ama ancak kendi verinizle kalibre edildiğinde. Örneğin bir servisin 0,9 güvenle döndürdüğü bir alanın sizin belgelerinizde ne sıklıkla doğru çıktığını test setinde ölçün; eşiği bu ölçüme ve o alandaki hatanın maliyetine göre alan alan belirleyin. Tutar ve vergi numarası için eşik, açıklama alanı için olandan yüksek olmalıdır.

İnsan incelemesi nasıl tasarlanmalı?

İnsan incelemesini her belgeye değil, kuralların ve eşiklerin yakaladığı belirsiz kayıtlara yönlendirin; otomatik geçen kayıtlardan da düzenli örnek alın. İyi bir inceleme tasarımında şunlar bulunur:

• Bir belge ancak tüm kontrollerden geçtiğinde ve kritik alanların hepsi eşiğin üstünde kaldığında otomatik aktarılır.
• İnceleyen kişi şüpheli alanı belge görüntüsünde işaretlenmiş hâliyle ve neden incelemeye düştüğüyle birlikte görür; belgeyi baştan okumak zorunda kalmaz.
• Her düzeltme kaydedilir: hangi alan, eski değer, yeni değer, kim, ne zaman. Bu kayıtlar hem denetim izi hem de bir sonraki ölçümün test verisidir.
• Otomatik aktarılan belgelerden düzenli aralıklarla rastgele örnek alınıp elle kontrol edilir; sessiz hatalar ancak böyle görünür.
• Ödeme gibi geri dönüşü zor adımlar otomasyonun değil, yetkili kişinin kararıdır.

İzlenecek göstergeler; otomatik geçen belge oranı, alan bazında düzeltme oranı, örnek denetimde bulunan hata ve incelemede bekleme süresidir. Bu göstergeler belge türüne ve tedarikçiye göre ayrı izlenmezse, bir tedarikçinin fatura şablonunu değiştirmesi ortalamanın içinde kaybolur. Onay adımı yazılımda nasıl zorlanır, sorusunu ajan eylemlerinden önce insan onayı yazımızda ele aldık.

Varsayımsal örnek: tedarikçi faturaları ERP'ye nasıl aktarılır?

Aşağıdaki örnek varsayımsaldır; sayılar yalnızca yöntemi göstermek içindir. Bir üretim şirketi ayda yaklaşık 2.000 tedarikçi faturası alıyor ve muhasebe ekibi bunları elle ERP'ye giriyor. Son üç ayın faturaları kanallara göre sayıldığında tablo şöyle çıkıyor:

Kanal	Pay (varsayımsal)	İşleme yolu
e-Fatura XML	%65	XML okuyucu, ardından doğrulama
e-Arşiv fatura (e-posta eki)	%15	XML alınabiliyorsa okuyucu, alınamıyorsa PDF metninden çıkarma
Yurt dışı PDF fatura	%12	Yerleşim modeli veya hazır fatura modeli
Kâğıt fatura (taranmış)	%8	OCR ve yerleşim modeli, daha yüksek inceleme oranı

Şirketin ilk kararı, faturaların büyük çoğunluğu için yapay zeka gerekmediğidir: XML okuyucu ve doğrulama kuralları bu kısmı karşılar. Model yatırımı kalan kısma, yani yurt dışı PDF'lere ve taranmış kâğıtlara yapılır. İkinci karar, aynı doğrulama kurallarının dört kanalın hepsine uygulanmasıdır. XML'den gelen bir faturada da sipariş ve irsaliye eşleşmesi, mükerrerlik ve IBAN kontrolü yapılır; çünkü yapılandırılmış veri doğru okunur ama yanlış bir fatura da yapılandırılmış olabilir.

Pilot için şirket her kanaldan ve en çok fatura kesen tedarikçilerden örnek seçer, doğru değerleri iki kişiye birbirinden bağımsız olarak işaretletir. Kabul ölçütleri pilot başlamadan yazılır: tutar ve vergi numarası alanlarında hedef doğruluk, otomatik geçen faturalarda örnek denetimde kabul edilebilecek en fazla hata ve incelemeye düşme gerekçelerinin listesi. Hedefler, bugünkü elle giriş hata oranı ölçülerek belirlenir; ölçülmemiş bir "yüzde 99" hedefi yazılmaz.

Belge işleme projelerinde sık yapılan hatalar neler?

En sık görülen hatalar modelden değil, ölçüm ve süreç tasarımından gelir:

• e-faturanın XML dosyası dururken PDF görüntüsünü OCR'a sokmak.
• Doğruluğu belge düzeyinde tek bir sayıyla ölçmek; alan, belge türü ve tedarikçi bazında bakmamak.
• Şemadaki her alanı zorunlu yapıp "bulunamadı" seçeneği bırakmamak.
• Satıcının kendi örnek belgeleriyle yaptığı demoyu kabul testi yerine koymak.
• Otomatik geçen kayıtları hiç örneklememek ve düzeltmeleri kaydetmemek; böylece aynı hatanın tekrar ettiğini görememek.
• Bir tedarikçi şablonunu değiştirdiğinde ya da yeni bir belge türü geldiğinde ne olacağını tanımlamamak.

Projeye başlamadan önce neyi netleştirmeli?

Belge kanallarını, alan listesini, doğrulama kurallarını, test setini ve kabul ölçütlerini model seçiminden önce netleştirin:

1. Belge envanteri: Türler, kanallar, aylık hacim, taranmış ve el yazısı içeren belgelerin payı, diller.
2. Alan listesi: Her belge türü için gereken alanlar, zorunlu olanlar ve hedef sistemdeki karşılıkları.
3. Doğrulama kuralları: Biçim, hesap, ana veri, belgeler arası eşleşme ve iş kuralları.
4. Test seti: Gerçek belgelerden, türe ve tedarikçiye göre dengeli seçilmiş, doğru değerleri iki kişi tarafından işaretlenmiş örnekler.
5. Veri konumu ve KVKK: Belgelerin hangi ortamda işleneceği, saklama ve silme kuralları.
6. Kabul ve inceleme: Alan bazında hedefler, eşikler, kimin neyi inceleyeceği.

Hazır servis mi, özel bir hat mı sorusunun cevabı da bu listeden çıkar. Belgeleriniz hazır modelin dil ve belge türü desteğine uyuyor, veri konumu şartlarınız da karşılanıyorsa hazır servis hızlı bir başlangıçtır; alma, doğrulama ve entegrasyon yine sizin tarafınızda kurulur. Belge türleriniz alışılmışın dışındaysa, veri kurum dışına çıkamıyorsa ya da çıkarma birkaç sistemi dolaşan bir iş akışının parçasıysa özel bir hat daha uygun olabilir. OCR, nesne tespiti ve görsel dil modelleri arasındaki farkı OCR ve görüntü tanıma yazımızda karşılaştırdık.

Fatura, sipariş ve sözleşme gibi belgelerden alan çıkarıp ERP kayıtlarıyla karşılaştıran ve tutarsızlıkları işaretleyen akışları, kritik adımlarda insan onayıyla birlikte yapay zeka ajanı geliştirme hizmetimiz kapsamında kuruyoruz. Belge karışımınızı ve doğrulama ihtiyacınızı birlikte değerlendirmek isterseniz ilk görüşme ve keşif çalışması ücretsizdir.