Yapay Zeka ile Belge İşleme

Belge otomasyonu projelerinin çoğu, model seçilmeden çok önce verilen küçük kararlarla başarılı ya da başarısız olur: hangi belgeyle başlanacağı, hangi alanların zorunlu sayılacağı, hangi kuralın bir kaydı durduracağı ve onay ekranına kimin bakacağı. Bu rehber, yapay zeka ile belge işleme kurmayı düşünen bir işletmenin bu kararları hangi sırayla vereceğini anlatır.

Metin bir satış broşürü değil; teklif aldığınız her ekibe sorabileceğiniz somut ölçütler, kendi belgelerinizle yapabileceğiniz hazırlıklar ve otomasyonun gereksiz olduğu durumlar burada açıkça yazıyor. Teknik terimler ilk geçtikleri yerde kısa bir cümleyle açıklanıyor.

01Uygunluğu belge envanteriyle ölçün

Otomasyonun size uygun olup olmadığını, son üç ayda gerçekten gelen belgeleri sayarak anlarsınız; tahminle verilen kararlar genellikle ya gereksiz bir proje ya da yarım kalmış bir kurulumla biter. Ortak klasörleri, e-posta kutularını ve tarayıcı çıktılarını bir hafta boyunca inceleyip basit bir tablo hazırlayın.

• Belge türü ve kaynağı: Tedarikçi faturası, masraf fişi, irsaliye, sözleşme ya da başvuru formu; her biri hangi kanaldan ve kimden geliyor.
• Aylık adet ve dağılım: Belgeler ay boyunca eşit mi geliyor, yoksa kapanış haftasında mı yığılıyor.
• Düzen çeşitliliği: Aynı türde kaç farklı tedarikçi ya da şablon var; tek bir büyük tedarikçi mi, yüzlerce küçük gönderici mi.
• Elle harcanan süre: Bir belgenin açılıp kontrol edilmesi ve sisteme girilmesi ortalama kaç dakika sürüyor.
• Hata maliyeti: Yanlış girilen bir tutar ne zaman ve kim tarafından fark ediliyor, düzeltmesi ne kadar emek istiyor.

Tablo üç durumda otomasyona karşı sinyal verir: adet düşükse, belgelerin büyük çoğunluğu zaten yapılandırılmış elektronik fatura olarak geliyorsa ya da her belge türü yılda yalnız birkaç kez görülüyorsa. Bu durumlarda muhasebe programınızın içe aktarma özelliği ve düzenli bir klasör yapısı daha az emekle aynı rahatlamayı sağlar. Tersine, düzeni sık değişen ve kapanışı kilitleyen tek bir belge türü varsa, ilk akış için doğru adayı bulmuşsunuz demektir.

02Şirket tipine göre ilk belge akışı

İlk akış, ekibin en çok vakit kaybettiği ve hatası en pahalıya patlayan belge türüyle başlamalıdır; her şeyi aynı anda otomatikleştirmeye çalışmak ölçümü imkansız kılar. Farklı işletmelerde bu aday belge genellikle şöyle ortaya çıkar:

• Toptancı ve distribütör: Çok sayıda tedarikçiden gelen alış faturaları ile sevk irsaliyeleri; ilk hedef sipariş satırlarıyla eşleştirmedir.
• Lojistik ve nakliye firması: Teslim tutanakları, imzalı irsaliye fotoğrafları ve gümrük evrakı; ilk hedef belgenin doğru sefere ve müşteriye bağlanmasıdır.
• Mali müşavirlik bürosu: Mükelleflerin karışık gönderdiği fiş, makbuz ve banka dökümleri; ilk hedef belgeleri mükellef ve döneme göre ayırmaktır.
• Sigorta acentesi ve aracı kurum: Hasar dosyasına eklenen ekspertiz raporu, ruhsat ve fatura fotoğrafları; ilk hedef eksik evrak listesini çıkarmaktır.
• Proje ve hizmet şirketi: Müşteri ve tedarikçi sözleşmeleri; ilk hedef taraf, süre, yenileme ve fesih tarihlerini bir listeye toplamaktır.

Mükelleflerinden belge toplayan bir büro, yapay zeka ile belge işleme kurmadan önce belgelerin tek bir yerden gelmesini sağlamalıdır; bunun için mali müşavir web sitesi içinde güvenli bir yükleme alanı iyi bir başlangıçtır. Dağınık kanallardan gelen belge, özenle kurulmuş bir okuma katmanını bile verimsiz bırakır. Seçilen ilk tür, sonraki akışların şablonu olur: aynı onay ekranı, aynı iz kaydı ve aynı ölçüm tablosu ikinci türde yeniden kullanılır.

03Sade dille mimari: girişten kayda yedi katman

Sağlam bir belge akışı, birbirinden ayrı çalışan ve ayrı ayrı test edilebilen katmanlardan oluşur. Teklif sunan ekipten bu katmanları sırayla anlatmasını isteyin; tek bir "yapay zeka okur ve yazar" cümlesi, hatanın nerede doğduğunu bulamayacağınız bir sistem anlamına gelir.

• Toplama: E-posta kutusu, paylaşılan klasör, tarayıcı ya da yükleme formu izlenir; her dosyaya benzersiz bir kimlik verilir ve özgün hali değişmez bir alana kopyalanır.
• Ön hazırlık: Çok sayfalı taramalar belgelere bölünür, eğik görüntüler düzeltilir, boş sayfalar ayıklanır. Kalitesi çok düşük görüntü bu aşamada geri çevrilebilir.
• Sınıflandırma: Belgenin türü belirlenir; fatura, irsaliye ve sözleşme farklı alan şemalarına gider.
• Çıkarma: OCR (optik karakter tanıma, yani görüntüdeki harfleri metne çevirme) ve üstündeki model, alanları adlandırır ve her biri için bir güven puanı üretir.
• Doğrulama: Kurallar çalışır; toplamlar, biçimler, mükerrer kontrol ve sipariş eşleşmesi sınanır.
• Onay: Kurala takılan ya da puanı eşiğin altında kalan belge bir kişinin ekranına düşer.
• Aktarım: Onaylanan kayıt hedef sisteme yazılır ve hangi belgeden üretildiği bağlantısıyla saklanır.

Bu ayrımın en büyük faydası değiştirilebilirliktir. Okuma servisi değiştiğinde yalnız çıkarma katmanı yeniden ölçülür; kurallar, onay ekranı ve entegrasyon yerinde kalır.

04Elektronik faturayı görüntüden okumayın

Yapılandırılmış gelen belgeyi yapay zekaya okutmak, hem gereksiz maliyet hem de gereksiz hata riski demektir. Türkiye'de elektronik faturanın UBL tabanlı XML aslı tutarı, vergiyi ve kalemleri zaten alan alan taşır; bu veri entegratörünüzden ya da muhasebe programınızdan doğrudan alınabilir.

Pratikte karışıklık şuradan çıkar: bazı tedarikçiler faturanın yalnız PDF görünümünü e-posta ekine koyar ve ekip bu PDF'i ayrı bir belge gibi işler. Akış kurulurken her gelen PDF için şu sıra izlenmelidir:

• Önce XML ara: Aynı fatura numarası entegratör kutunuzda XML olarak duruyorsa PDF yalnız görsel kopya sayılır ve okunmaz.
• Sonra eşleştir: PDF ile XML aynı faturaya aitse kayıt XML'den oluşur, PDF arşive bağlanır.
• En son modele gönder: Yalnız XML karşılığı bulunmayan kâğıt, tarama, fotoğraf ve yurt dışı faturaları okuma katmanına gider.

Bu basit ayrım iki faydayı birlikte getirir. Modelin okuduğu belge sayısı azalır ve kullanım bedeli düşer; ayrıca aynı faturanın biri XML'den, biri PDF'ten olmak üzere iki kez kayda girmesi engellenir. Yurt dışından gelen faturalarda ise durum farklıdır: göndericinin kendi ülkesindeki yapılandırılmış formatı kabul edip edemeyeceğinizi muhasebecinizle konuşun, aksi halde bu belgeler okuma katmanının ana iş yükü olur.

05Alan şeması ve sağlama kuralları

Alan şeması, her belge türünden hangi bilginin hangi biçimde çıkarılacağını tanımlayan yazılı listedir ve akışın sözleşmesi sayılır. Şema net değilse model her seferinde biraz farklı bir çıktı üretir, hedef sistem de bu farkları sessizce kabul eder. Her alan için adı, veri tipi, zorunlu olup olmadığı ve standart biçimi yazılmalıdır: tarih tek bir biçimde, ondalık ayıracı tek bir karakterle, para birimi uluslararası üç harfli kodla.

Ardından her belge türü için sağlama kuralları listelenir. Fatura için tipik bir başlangıç seti şöyledir:

• Aritmetik tutarlılık: Kalem tutarlarının toplamı matrahı, matrahın oranla çarpımı vergi tutarını, ikisinin toplamı genel toplamı vermeli.
• Kimlik biçimi: Vergi kimlik numarası on, T.C. kimlik numarası on bir hanelidir ve her ikisinin de bir kontrol hanesi algoritması vardır; algoritmayı geçemeyen numara okunmuş sayılmaz.
• Tarih mantığı: Fatura tarihi gelecekte olamaz, vade tarihi fatura tarihinden önce olamaz.
• Mükerrer kontrol: Aynı gönderici, aynı fatura numarası ve aynı tutar daha önce kayda girdiyse belge durur.
• Sipariş eşleşmesi: Satın alma siparişi ve irsaliyeyle miktar ve fiyat karşılaştırılır; belirlediğiniz toleransı aşan fark onaya gider.

Aynı dosyanın farklı adla ikinci kez yüklenmesini yakalamak için içerik özetini, yani dosyadan üretilen sabit uzunluklu parmak izini kullanın; mantığını hash hesaplama aracıyla kendi dosyalarınızda deneyebilirsiniz. İki dosyanın özeti aynıysa içerikleri de birebir aynıdır.

06Kaynak kanallar ve hedef sistem bağlantıları

Belge akışının girişi ve çıkışı, okuma katmanı kadar önemlidir; kanal dağınıksa ya da hedef sistem kayıt kabul etmiyorsa en isabetli model bile işe yaramaz. Giriş tarafında her kanal için kimin belge gönderebileceğini, hangi dosya türlerinin kabul edileceğini ve dosya boyutu sınırını yazın.

Çıkış tarafında ilk soru, hedef sistemin kaydı nasıl aldığıdır. Muhasebe programları, ERP ve CRM yazılımları genellikle şu üç yoldan biriyle beslenir:

• Belgelenmiş API: Kayıt doğrudan ve anında oluşur; hata mesajı akışa geri döner ve kuyrukta görünür.
• İçe aktarma dosyası: Onaylı kayıtlar belirli aralıklarla dosya halinde aktarılır; daha yavaştır ama birçok yerel muhasebe programında en güvenli yoldur.
• Ara tablo: Akış kendi veritabanına yazar, hedef sistem bu tabloyu okur; eski ve kapalı sistemlerde son çare olarak kullanılır.

Hangi yol seçilirse seçilsin iki kural değişmez. Birincisi, her kayıt tekrar gönderildiğinde ikinci bir kayıt oluşturmamalıdır; ağ kesintisinden sonra yeniden deneme yapılması mükerrer fatura doğurmamalı. İkincisi, akış muhasebe hesap kodunu önerebilir ama ilk aylarda bu kodu kesinleştirmemelidir; öneri onay ekranında görünür, kararı muhasebeci verir. Hedef sistemin hiç bağlantı noktası yoksa küçük bir aracı servis ya da iç panel gerekir; bu iş özel yazılım geliştirme kapsamında ayrıca planlanır.

07Model seçimi ve barındırma seçenekleri

Okuma katmanı için üç ana seçenek vardır ve doğru olanı kendi test setiniz belirler, sağlayıcının tanıtım sayfası değil. Hazır belge okuma servisleri fatura ve kimlik gibi yaygın türlerde hızlı başlangıç sunar; görüntüyü ve metni birlikte yorumlayabilen genel amaçlı modeller düzeni sık değişen ve serbest metinli belgelerde esneklik sağlar; kendi sunucunuzda çalışan açık modeller ise veriyi şirket içinde tutar.

Seçimi şu ölçütlerle, aynı test seti üzerinde karşılaştırın:

• Türkçe karakter doğruluğu: Ş, ğ, ı ve İ harflerinin firma adlarında ve adreslerde doğru okunup okunmadığı.
• Tablo ve çok sayfa başarısı: Sayfa sonunda bölünen kalem tablolarının tek tablo olarak birleştirilip birleştirilmediği.
• Güven puanının anlamı: Yüksek puanlı alanların gerçekten daha az hatalı olup olmadığı; puan ile hata arasında ilişki yoksa eşik de işe yaramaz.
• Sürüm sabitleme: Belirli bir model sürümünün seçilip seçilemediği ve sürüm kaldırılmadan önce ne kadar önceden haber verildiği.
• Veri koşulları: Gönderilen belgenin eğitimde kullanılıp kullanılmadığı, ne kadar saklandığı ve hangi bölgede işlendiği.

Sağlık raporu ya da kimlik belgesi gibi hassas evrak işleyen işletmeler için yerel LLM kurulumu ciddi bir seçenektir; ancak donanım, güncelleme ve güvenlik sorumluluğu size geçer. Çoğu işletme için en dengeli yapı, hassas türleri yerel modelde, diğerlerini sözleşmesi incelenmiş bir bulut servisinde işleyen karma kurulumdur.

08Onay ekranı, güven eşiği ve iz kaydı

Onay ekranı, yapay zeka ile belge işleme akışında insanın en çok zaman geçireceği yerdir; kötü tasarlanırsa otomasyonun kazandırdığı süre burada geri harcanır. İyi bir ekran belge görüntüsünü ve çıkarılan alanları yan yana gösterir, her alanın belgede okunduğu bölgeyi işaretler ve yalnız şüpheli alanları renklendirir. Onaylayan kişi bütün belgeyi değil, yalnız işaretli alanları kontrol eder.

Eşik, tek bir sayı olarak değil alan bazında belirlenir. Tedarikçi adındaki küçük bir okuma farkı ana kayıtla eşleştirmede kendiliğinden düzelir; genel toplamdaki tek bir rakam hatası ise doğrudan para kaybıdır. Bu yüzden tutar ve vergi numarası alanları için eşik sıkı, açıklama alanları için daha esnek tutulur. Belirli bir tutarın üstündeki belgelerde, puan ne olursa olsun ikinci bir kişinin onayı istenebilir.

Her belge için tutulacak iz kaydı en az şunları içermelidir:

• Dosyanın geliş zamanı, kanalı ve içerik özeti.
• Okumada kullanılan servis ya da model ile sürüm bilgisi.
• Her alanın ilk okunan değeri, güven puanı ve varsa düzeltilmiş hali.
• Onaylayan ya da reddeden kişinin adı, zamanı ve gerekçesi.
• Hedef sistemde oluşan kaydın numarası ve gerekirse geri alma işlemi.

Düzeltilen her alan değerlidir: bu kayıtlar haftalık olarak incelenir ve tekrar eden düzeltmeler test setine yeni örnek olarak eklenir.

09KVKK, özel nitelikli veri ve yurt dışı aktarım

Belgeler çoğu zaman kişisel veri taşır; faturadaki şahıs şirketi adı, başvurudaki kimlik numarası, sağlık raporundaki teşhis bunlara örnektir. Bu yüzden kurulumdan önce her belge türünün hangi kişisel veriyi içerdiğini, akışın hangi adımında nereye gittiğini ve ne kadar saklandığını gösteren bir veri akışı haritası çıkarılmalıdır.

• Özel nitelikli veri: KVKK'nın 6. maddesi sağlık, ceza mahkûmiyeti, biyometrik ve genetik verileri özel nitelikli sayar. Bu verileri içeren belge türleri ayrı bir akışta, daha dar erişimle ve mümkünse maskelenerek işlenir.
• Yurt dışına aktarım: Okuma servisi yurt dışındaysa belge içeriği aktarılmış olur. 9. maddeye göre yeterlilik kararı yoksa standart sözleşme gibi bir güvence gerekir; standart sözleşme imzalandıktan sonra beş iş günü içinde Kurum'a bildirilir.
• Otomatik karar: 11. madde, yalnız otomatik sistemlerle yapılan analiz sonucunda kişinin aleyhine çıkan sonuca itiraz hakkı tanır. Akış belgeyi okur ve eksik listesi çıkarır; başvuruyu reddetmez.
• Erişim ve saklama: Onay ekranını kimin göreceği rolle sınırlanır; özgün belge ve çıkarılan verinin saklama süresi muhasebeciniz ve hukukçunuzla yazılı olarak belirlenir.

AB'de faaliyet gösteren ya da AB'deki kişilerin belgelerini işleyen şirketler için GDPR ve AB Yapay Zeka Tüzüğü de gündeme gelir. Tüzük, işe alım ve kredi değerlendirmesinde kullanılan yapay zekayı Ek III'te yüksek riskli sayar; özgeçmiş ayıklayan ya da kredi dosyası puanlayan bir akış, basit fatura okumadan çok farklı bir yükümlülük seti taşır. Hukuki değerlendirme hukukçunuza aittir; teknik ekip veri akışı haritasını, sağlayıcı sözleşmelerini ve ayarları belgeler.

10Pilottan tam kullanıma devreye alma

Akış tek seferde canlıya alınmaz; her adım bir öncekinin ölçümüne dayanarak ilerler. Aşağıdaki sıra, tek bir belge türü için çoğu işletmede işe yarayan iskelettir.

1. Örnek seti toplayın: Seçilen türden son aylara ait, farklı göndericileri ve kötü taramaları da içeren anonimleştirilmiş örnekler ayrılır.
2. Doğru cevapları yazın: Her örnek için alanların doğru değerleri elle girilir; bu tablo bundan sonraki her ölçümün referansıdır.
3. Prototipi ölçün: Okuma ve kural katmanı yalnız bu set üzerinde çalıştırılır, alan bazında hata listesi çıkarılır.
4. Gölge çalıştırın: Akış gerçek belgeleri okur ama kayda yazmaz; ekip her zamanki gibi çalışır, iki sonuç her gün karşılaştırılır.
5. Dar devreye alın: Önce tek bir gönderici grubu ya da belirli bir tutarın altındaki belgeler onaysız geçebilir; diğerleri onay ekranında kalır.
6. Kapsamı genişletin: Hata listesi kabul edilen düzeyde kaldıkça yeni göndericiler, sonra ikinci belge türü eklenir.

Gölge çalışma dönemi sabırsızlıkla en sık kısaltılan adımdır, oysa akışın gerçek belgelerdeki davranışını gösteren tek yer burasıdır. Ay kapanışını en az bir kez kapsayacak uzunlukta tutulması önerilir; kapanış haftasındaki yoğunluk ve aceleyle taranan belgeler normal günlerde görülmeyen hataları ortaya çıkarır.

11Kazanılan zamanı ve doğruluğu ölçmek

Değer tek bir oranla değil, birbirini dengeleyen birkaç ölçüyle anlaşılır; onaysız geçiş artarken düzeltme sayısı da artıyorsa akış hızlanmış ama bozulmuştur. Ölçüme başlamadan önce mevcut durumu kaydedin: otomasyondan önceki birkaç hafta boyunca belge başına harcanan süreyi çalışma saati hesaplama aracıyla tutmak, sonraki karşılaştırmanın tek sağlam temelidir.

• Alan bazında hata: Haftalık rastgele örneklemde her alanın doğru, düzeltilmiş ya da boş bırakılmış olma oranı.
• Onay kuyruğunda bekleme: Belgenin kuyruğa düşmesinden onaylanmasına kadar geçen süre; kuyruk birikiyorsa eşik değil kişi planı değişmelidir.
• Kapanış takvimi: Ay sonu kapanışının kaçıncı iş gününde tamamlandığı, otomasyon öncesindeki aylarla karşılaştırılır.
• Geri dönen hata: Kayda girdikten sonra tedarikçi, müşteri ya da denetim tarafından yakalanan yanlışların sayısı.
• Belge başına kullanım bedeli: Model ve okuma servisinin faturası, işlenen belge sayısına bölünerek aylık izlenir.

Rakamları yorumlarken mevsimselliği hesaba katın. Yıl sonu, bayram öncesi ya da kampanya dönemindeki belge yükü, otomasyonun etkisini olduğundan büyük ya da küçük gösterebilir.

Ölçüm tablosunu aylık olarak muhasebe sorumlusu ve akışı kuran ekip birlikte okumalıdır. Yapay zeka ile belge işleme kurulduktan sonra en sık görülen yanılgı, onaysız geçiş oranının tek başına başarı sayılmasıdır; oysa asıl soru, ekibin kazandığı zamanı kontrol ve analiz için kullanıp kullanmadığıdır.

12Sınırlar ve gözden kaçan riskler

Yapay zeka ile belge işleme okuma hatasını azaltır ama ortadan kaldırmaz; bazı riskler de klasik OCR'da hiç yoktu. Kurulumdan önce bu sınırların her biri için bir tedbir yazılmalıdır.

• Uydurulmuş değer: Dil modelleri okunamayan bir alanı boş bırakmak yerine makul görünen bir değerle doldurabilir. Talimat, okunamayan alanın boş dönmesini açıkça istemeli; kurallar da bu boşluğu yakalamalıdır.
• Belgeye gizlenmiş talimat: Bir PDF'in içine insan gözünün görmediği bir metin eklenerek modelin davranışı değiştirilmeye çalışılabilir. Okuma katmanının yalnız alan çıkarma yetkisi olmalı; hiçbir belge içeriği akışa komut veremez.
• Sessiz sürüm değişikliği: Sağlayıcı modeli güncellediğinde aynı belge farklı okunabilir. Sürüm sabitlenir, her değişiklikte test seti yeniden çalıştırılır.
• Kaşe, imza ve el notları: Tutarın üstüne basılmış kaşe ya da kenara yazılmış düzeltme, modelin hangi değeri seçeceğini belirsizleştirir; bu belgeler sıkı eşikle onaya gider.
• Uzun belgeler: Onlarca sayfalık sözleşmelerde model ilgili maddeyi atlayabilir; her çıkarımın sayfa ve madde numarasıyla birlikte verilmesi şart koşulur.

Bu tedbirler riski yönetilebilir kılar ama sıfırlamaz. Bu nedenle onay kuyruğu, akış ne kadar olgunlaşırsa olgunlaşsın kapatılmaz; yalnız daralır.

13Belge otomasyonunda sık yapılan hatalar

Belge projelerinde yaşanan sorunların çoğu modelden değil, hazırlık ve devreye alma sırasından kaynaklanır. Aşağıdaki hataların her biri için daha iyi bir yol vardır.

• Demo belgesiyle karar vermek: Sağlayıcının temiz örnek faturasında kusursuz görünen okuma, sizin bulanık fiş fotoğraflarınızda başka sonuç verir; kararı kendi örnek setinizle verin.
• Elektronik faturayı da modele okutmak: XML aslı varken PDF görünümünü okumak hem bedel hem mükerrer kayıt üretir; yapılandırılmış veriyi önce ayırın.
• Tek bir genel eşik kullanmak: Bütün alanlara aynı güven eşiğini vermek ya gereksiz onay yükü ya da tehlikeli geçiş üretir; eşiği alan ve tutar bazında belirleyin.
• Onay ekranını sonraya bırakmak: Okuma katmanına odaklanıp onay ekranını basit bir tabloyla geçiştirmek, kazanılan zamanı kuyrukta harcatır; ekranı ilk prototiple birlikte tasarlayın.
• Gölge dönemi atlamak: Test setinde iyi sonuç veren akışı doğrudan kayda bağlamak, gerçek belgelerdeki hatayı muhasebeye taşır; en az bir kapanış dönemi paralel çalıştırın.
• Düzeltmeleri kaybetmek: Onay ekranında yapılan düzeltmeler kayda geçmezse akış aynı hatayı tekrar eder; her düzeltmeyi iz kaydına ve test setine bağlayın.

Bu listeye çoğu projede bir madde daha eklenir: muhasebe ekibini tasarıma geç dahil etmek. Onay ekranını kullanacak kişiler alan şemasını ve kuralları ilk günden görmezse, akış teknik olarak doğru ama günlük işe uymayan bir araca dönüşür.

14İş ortağı seçimi ve sonraki adım

Doğru iş ortağı, ilk görüşmede bir okuma demosundan önce belge örneklerinizi, hedef sisteminizi ve kapanış takviminizi sorar. Yapay zeka ile belge işleme teklifi alırken şu noktalarda yazılı açıklık isteyin:

• Doğruluk hangi örnek set üzerinde, alan bazında mı yoksa belge bazında mı ölçülecek?
• Yapılandırılmış elektronik faturalar akıştan nasıl ayrılacak?
• Okuma servisi değiştirildiğinde kurallar, onay ekranı ve entegrasyon yeniden yazılmak zorunda kalacak mı?
• Model, okuma servisi ve otomasyon hesapları kimin adına açılacak, alan şeması ve kurallar teslimde kime geçecek?
• Veri akışı haritası ve sağlayıcı sözleşmelerinin kontrol listesi kapsamda mı?

Bu işleri yapay zeka otomasyonu hizmetimiz içinde yürütüyoruz. Yapay zeka ile belge işleme alanında referans gösterebileceğimiz yayında bir müşteri projemiz henüz bulunmadığı için sonuç vaadi yerine yöntemimizi anlatıyoruz; otomasyon, yazılım ve web çalışmalarımızı referanslarımız arasında görebilirsiniz.

Bedeli belge türü sayısı, hacim, bağlanacak sistemler ve bakım kapsamı belirler; keşif ve ilk akış için sabit fiyatlı seçenekler fiyat sayfamızda yer alıyor. En çok vakit alan belge türünüzü, yaklaşık aylık adedi ve verinin yazılacağı sistemi iletişim formu üzerinden paylaştığınızda alan şemasını, onay kurallarını ve yazılı teklifi birlikte netleştiriyoruz.