Faturayı okumak başka, anlamak başka: bir havayolunda yerinde belge işleme

Bir faturanın üzerindeki yazıyı okumak bugün zor bir iş değil. OCR motorları bunu yıllardır iyi yapıyor. Zor olan, okunan şeyin ne olduğunu anlamak: hangi tutar toplam, hangisi satır? Hangi tarih fatura tarihi, hangisi vade? İkinci sayfadaki tablo birincinin devamı mı, yoksa ayrı bir döküm mü?

Ulusal bayrak taşıyıcı bir havayolunun Finans ve Muhasebe birimi için kurduğumuz belge işleme programı bu ikinci sorunun üstüne kurulu. Program kurumun kendi veri merkezinde çalışıyor, tedarikçi faturalarını uçtan uca işliyor ve canlıda. Bu yazıda kurumun iç detaylarına girmeden, tasarımı belirleyen kararları anlatıyorum.

Bir tedarikçi faturasının hattaki yolu

Akışın iskeleti. Kurumun iç detaylarını ve hacimlerini paylaşmıyorum; adımlar bu tür bir programın nasıl kurulduğunu gösteriyor. Bir adıma tıklayın ya da oynatın.

1. 01Alım
2. 02Sayısallaştırma
3. 03Sınıflandırma
4. 04Çıkarım
5. 05Kural kontrolü
6. 06İnsan doğrulaması
7. 07Kayıt ve iz

Sistem

Alım

Fatura hangi kanaldan gelirse gelsin (e-posta, tarama, portal) tek bir giriş kuyruğuna düşer. Her belgeye izlenebilir bir kimlik verilir; aynı belgenin ikinci kez gelmesi burada yakalanır.

Model

Sayısallaştırma

OCR/ICR belgeyi metne ve konum bilgisine çevirir. Kurulum kurumun kendi veri merkezinde çalıştığı için belge hiçbir aşamada dışarı çıkmaz.

Model

Sınıflandırma

Belgenin türü ve dili belirlenir. Fatura, irsaliye ve ek sayfalar aynı dosyada gelebilir; çıkarım ancak tür doğru belirlendikten sonra anlam taşır.

Model

Çıkarım

Başlık alanları (tedarikçi, tarih, vade, para birimi) ve satır tabloları çıkarılır. Birden fazla tablo, sayfa sonunda bölünen tablolar ve ülkeye göre değişen ondalık gösterimleri bu adımın işi.

Kural

Kural kontrolü

Satırların toplamı fatura toplamını tutuyor mu, para birimi tedarikçiyle uyumlu mu, tedarikçi ana veride kayıtlı mı? Her alanın güven skoru, o alan için belirlenen eşikle karşılaştırılır.

İnsan

İnsan doğrulaması

Eşiğin altında kalan ya da bir kuralı geçemeyen belge doğrulama ekranına düşer. Kişi belgeyi baştan okumaz; yalnızca takılan alanı ve takılma nedenini görür.

Sistem

Kayıt ve iz

Onaylanan veri ERP’ye yazılır. Kimin neyi düzelttiği denetim izine kaydedilir; düzeltilen alanlar bir sonraki model iyileştirmesinin girdisi olur.

Önceki Oynat Sonraki 1 / 7

İlk kısıt: belge binadan çıkmayacak

Mimariyi belirleyen ilk karar teknik değil, kurumsaldı: belgeler kurumun dışına gönderilmeyecek. Finans belgelerinde bu sık rastlanan bir şart ve bence haklı bir şart. Tedarikçi faturası; banka bilgisi, sözleşme fiyatı ve ödeme takvimi taşır.

Bunun sonucu, bulutta birkaç ayarla açılan pek çok şeyin yerinde bir altyapı işine dönüşmesi. Sayısallaştırma ve çıkarım bileşenleri kurum içinde çalışmak zorunda. Model sürümleri, güncellemeler ve kapasite planı da projenin parçası oluyor. UiPath kendi dokümantasyonunda Document Understanding’in Automation Suite ve Standalone kurulumlarda sunulmaya devam ettiğini açıkça yazıyor. Yerinde çalışma şartı olan kurumlar için bu, ürün seçimini daraltan bir bilgi.

Bence buradan çıkacak ders basit: yerinde kurulumu ayrı bir iş kalemi olarak planlayın. Dağıtımın bir alt maddesi sayılırsa, zaman çizelgesinde bir yerde sıkışır.

Okumakla anlamak arasındaki üç zorluk

Bu programın kapsamı üç kelimeyle özetlenebilir: çok para birimi, çok dil, çok tablo. Her biri ayrı bir problem.

Çok para birimi. Tutarın yanında para birimi her zaman yazmaz. Ondalık ayırıcı ülkeden ülkeye değişir ve aynı tedarikçi farklı dönemlerde farklı biçim kullanabilir. Çıkarım sonrasında her tutarın tek bir gösterime çevrilmesi ve para biriminin tedarikçinin beklenen para birimiyle karşılaştırılması gerekir. Bu karşılaştırmayı kurala bırakırım. Model yanılabilir; “bu tedarikçi bize hep avroyla fatura keser” bilgisi ise ana veride zaten var.

Çok dil. Aynı alan farklı dillerde farklı etiketlerle gelir. Latin alfabesi dışındaki yazılar ayrı bir zorluk. Başka bir projede Çince karakterli belgeler için ayrı bir çıkarım hattı kurduk ve bu hat doğruluğu %55 artırdı. Bu sonuç bir şeyi gösteriyor: bütün dilleri tek bir modelle çözmeye çalışmak yerine sorunlu dili ayırıp kendi hattına almak denemeye değer.

Çok tablo. Satır kalemleri birden fazla tabloya dağılabilir, tablolar sayfa sonunda bölünebilir, ara toplamlar satır gibi görünebilir. Burada en iyi sigorta yine bir kural: satırların toplamı fatura toplamını tutmuyorsa belge otomatik geçmez.

İnsan doğrulaması bir yedek değil, tasarımın kendisi

Bu programın iki ayırt edici parçası doğrulama ekranının tasarımı ve yapılandırılmış insan eskalasyonu. İkincisi kulağa soyut geliyor, o yüzden açayım.

Yapılandırılmamış eskalasyonda belge bir kişiye “kontrol eder misiniz?” notuyla gider. Kişi belgeyi baştan okur, neyin yanlış olduğunu kendisi bulur ve her seferinde aynı işi tekrarlar. Yapılandırılmış eskalasyonda ise belge, takıldığı yerle birlikte gelir: hangi alan, hangi kural, hangi güven skoru. Nedeni farklı olan belgeler farklı kişilere gidebilir. Okunamayan bir alan doğrulama ekibinin işidir; ana veride olmayan bir tedarikçi ise satın almanın.

Bunun iki faydası var. Doğrulayan kişi zamanını yalnızca şüpheli alana harcar. İkincisi, düzeltmeler nedenleriyle birlikte kaydedildiği için hangi belge tipinin, hangi alanın sorun çıkardığı ölçülebilir hâle gelir. Model iyileştirmesine nereden başlanacağına bu kayıtlar karar verir.

Güven eşiklerini alan bazında koyarım, belge bazında değil. Tedarikçi adındaki küçük bir okuma hatası ana veri eşleşmesiyle yakalanır; tutardaki bir hata ise kimse fark etmeden ödemeye dönüşebilir. Aynı eşiği ikisine uygulamak mantıklı değil.

Bu kurguyu kopyalamadan önce

Benzer bir programa başlayacak bir ekibe şu listeyi verirdim:

1. Gerçek bir aylık belge örneği toplayın. Tedarikçi, dil, para birimi ve sayfa sayısı dağılımını görmeden tahmin yapmayın.
2. Doğrulama ekranına kimin bakacağını ve haftada ne kadar zamanı olduğunu baştan yazın. İnsan adımı kapasitesiz bir kuyruğa dönüşürse otomasyon yavaşlar.
3. Hangi alanın hangi eşikle geçeceğine iş birimiyle birlikte karar verin ve bu kararın sahibini belirleyin.
4. ERP’ye yazmadan önce son tutarlılık kontrollerini kural olarak tanımlayın. Model ne kadar iyi olursa olsun bu kontrolleri modele bırakmayın.
5. Yerinde kurulum varsa donanım, OCR motoru lisansı ve model güncelleme prosedürünü proje planına ayrı satır olarak koyun.
6. Model sürümü değiştiğinde geri dönüş planınız olsun. Yeni sürüm bir alanda iyileşip başka bir alanda kötüleşebilir.

Bu listedeki maddelerin hiçbiri yapay zekâ ile ilgili değil. Belge işleme projelerinde sonucu belirleyen kararların çoğu da öyle.