# Fatura işleme otomasyonu: OCR, insan onayı ve ERP entegrasyonu

*2026-09-29 · 16 dk*

Fatura otomasyonunu OCR ve Document AI'dan insan onayına, 3-way match, istisna yönetimi ve ERP entegrasyonuna kadar tasarlamak için kapsamlı uygulama rehberi.


Bir kurumun gelen kutusunda bekleyen fatura sayısı, finans ekibinin gerçek iş yükünü tek başına göstermez. Aynı belge farklı kanallardan gelebilir, tedarikçi adı ana veride farklı yazılabilir, sipariş kısmi teslim edilmiş olabilir veya faturadaki kalem açıklaması satın alma talebindeki ifadeyle eşleşmeyebilir. Bu nedenle fatura otomasyonu “PDF'den Excel'e veri çıkarma” projesi olarak başladığında, en kritik kontrol noktaları daha ilk günden dışarıda kalır.

Uçtan uca tasarım; belgeyi alma, OCR ve Document AI ile anlama, ana veri doğrulama, sipariş–mal kabul–fatura eşleştirme, istisna yönlendirme, insan onayı, ERP kaydı, ödeme ve mutabakat adımlarını birlikte ele alır. [Procure Suite Pro](/urunler/procure-suite-pro) talep, teklif, sipariş, tedarikçi ve fatura bağlamını aynı satın alma omurgasında tutarken; [alfi Automate](/urunler/aile/automate) invoice ve approve yetenekleri tetikleyici–onay akışlarını, [alfi Engines](/urunler/aile/engines) docs yeteneği belge anlama katmanını destekler.

## Fatura otomasyonu nedir?

Fatura otomasyonu, bir faturanın kuruma ulaşmasından muhasebe veya ödeme sistemine kontrollü şekilde işlenmesine kadar geçen sürede tekrarlı veri girişini ve manuel takip yükünü azaltan iş akışıdır. Sistem yalnızca karakter tanımaz; belgenin fatura mı, proforma mı, irsaliye mi, dekont mu veya mükerrer bir kopya mı olduğunu belirler. Daha sonra belge ile kurum kayıtları arasındaki ilişkiyi kurar.

Başarı üç katmanda ölçülmelidir. Birinci katman belge doğruluğudur: tarih, numara, vergi numarası, para birimi, KDV, kalem ve toplam doğru çıkarılmış mı? İkinci katman süreç doğruluğudur: doğru sipariş, mal kabul ve maliyet merkezine bağlanmış mı? Üçüncü katman finansal sonuçtur: ERP'de doğru kayıt açılmış, ödeme durumu takip edilmiş ve mutabakat yapılmış mı? İlk katman iyi olsa bile diğer ikisi yoksa otomasyon yalnızca hızlı bir hata üretir.

## Mevcut süreci ölçmeden teknoloji seçmeyin

İlk adım son üç veya altı aylık fatura akışının örneklenmesidir. PDF, taranmış görüntü, e-fatura çıktısı, e-arşiv, e-posta eki ve portal indirimi ayrı sayılır. Hangi tedarikçilerin standart format kullandığı, hangi kalemlerin siparişle eşleştiği, hangi faturaların hizmet veya masraf niteliğinde olduğu belirlenir. Ortalama hacim kadar pik dönem ve istisna hacmi de kayda alınır.

Süreç haritasında her elle yapılan adımın nedeni yazılmalıdır. Bir kişi belgeyi başka bir sisteme taşıyorsa bunun sebebi güvenlik, eksik entegrasyon, onay yetkisi veya sadece alışkanlık olabilir. Otomasyon kararı gerçek nedeni çözmeden verildiğinde eski kontrol başka bir ekranda yeniden ortaya çıkar. [Sistem entegrasyonu ve veri mühendisliği](/hizmetler/sistem-entegrasyonu-veri-muhendisligi) çalışmaları bu haritayı API, dosya ve ana veri sahipliğiyle teknik tasarıma dönüştürür.

## Belge alımı ve güvenli gelen kutusu

Faturanın nereden geldiği ilk güvenlik sınırıdır. Kurumsal e-posta, e-fatura entegratörü, tedarikçi portalı ve manuel yükleme farklı güven politikalarına sahip olabilir. Dosya uzantısına güvenmek yerine MIME tipi, virüs taraması, dosya hash’i, gönderen doğrulaması ve mükerrer kontrolü uygulanır. Aynı belge tekrar geldiğinde yeni bir kayıt açılmamalı; önceki kaydın durumu ve yeni kopyanın neden geldiği gösterilmelidir.

Gelen belge ham haliyle değiştirilemez bir depoya alınmalı, işleme için kopyası kullanılmalıdır. Dosya adı, gönderen, zaman, kanal, tenant ve ilişkilendirilen tedarikçi meta verisiyle tutulur. Hassas finans ve kişi verileri için erişim rolü, saklama süresi ve silme politikası belirlenir. [alfi Guard](/urunler/aile/guard) erişim, maskeleme ve audit katmanlarıyla belgeyi yalnızca okumaya yetkili ekiplerin görmesini sağlar.

## OCR neyi çözer, neyi çözemez?

OCR, görüntüdeki şekilleri karakterlere ve kelimelere dönüştürür. Düşük çözünürlüklü tarama, eğik sayfa, damga, el yazısı, çok sütunlu tablo veya Türkçe karakterler doğruluğu etkileyebilir. OCR çıktısına koordinat ve güven skoru eklenirse sistem “toplam” alanının belgedeki hangi bölgeden geldiğini gösterebilir. Bu kanıt, insan doğrulamasını hızlandırır.

OCR bir iş kuralı değildir. 10.000,00 TL ifadesini okumak başka; bunun brüt mü net mi, KDV dahil mi, sipariş kalemiyle uyumlu mu olduğunu bilmek başkadır. Belge türü sınıflandırma, tablo yapılandırma, tedarikçi ana veri eşleştirme ve matematiksel kontrol OCR'dan sonra gelir. [Doküman anlama ve akıllı belge işleme](/hizmetler/yapay-zeka-yazilim-gelistirme/dokuman-anlama-akilli-belge-isleme) hizmeti bu katmanların birlikte tasarlanmasına odaklanır.

## Alan çıkarımı ve kaynak kanıtı

Zorunlu alanlar tedarikçi tipine ve belge türüne göre değişir. Genel bir faturada vergi kimlik numarası, fatura numarası, tarih, vade, para birimi, satır kalemleri, ara toplam, indirim, vergi ve genel toplam bulunabilir. Hizmet faturasında miktar yerine dönem, sözleşme veya hizmet kabul bilgisi gerekir. Sistem bilinmeyen alanı boş bırakmalı; tahmin ederek finansal kayıt üretmemelidir.

Her alan değerle birlikte güven skoru, kaynak koordinatı ve doğrulama durumunu taşımalıdır. Toplam ile satırların matematiksel toplamı uyuşmuyorsa belgenin “yüksek güvenli” sınıfı bozulur. Tedarikçi vergi numarası ana veriyle eşleşmiyorsa modelin şirket adını benzetmesi yeterli değildir. İnsan ekranı alanın çıkarılan değerini ve görüntüdeki bölgesini aynı anda göstermelidir.

## 3-way match: sipariş, mal kabul ve fatura

3-way match, satın alma siparişi, mal kabul kaydı ve faturanın miktar, fiyat ve kimlik bilgilerini karşılaştırır. [3-way match](/sozluk/3-way-match) kuralı “hepsi bire bir aynı olmalı” demek değildir; kısmi teslim, tolerans, navlun, vergi, fiyat farkı ve hizmet satırı gibi iş kurallarıyla birlikte çalışır. Match sonucu eşleşti, tolerans içinde, açıklama gerekli veya reddedildi gibi sınıflara ayrılmalıdır.

Mal kabul kaydı yoksa faturayı otomatik reddetmek her zaman doğru değildir. Danışmanlık, kira, abonelik veya dönemsel hizmetlerde kabul kanıtı farklı olabilir. Bu nedenle ürün, hizmet, masraf ve varlık faturaları ayrı akışlara girmelidir. [GRN](/sozluk/grn) kaydı bulunmayan bir fiziksel ürün faturası için satın alma veya depo sorumlusuna görev açılması, finans ekibinin belgeyi e-posta ile takip etmesinden daha izlenebilirdir.

## Ana veri kalitesi otomasyonun gizli belirleyicisidir

Tedarikçi ana verisindeki mükerrer kayıt, pasif hesap, yanlış vergi numarası veya farklı banka bilgisi fatura akışını doğrudan etkiler. Tedarikçi adını benzerlik algoritmasıyla eşleştirmek, yanlış şirkete ödeme riskini ortadan kaldırmaz. Vergi numarası, IBAN onay süreci, sözleşme kimliği ve aktiflik durumu doğrulama için birlikte kullanılmalıdır.

Malzeme, hizmet, maliyet merkezi, proje kodu ve vergi kodu da aynı özeni gerektirir. Satın alma talebindeki kod ile ERP hesabı arasında dönüşüm varsa bunun sahibi ve yürürlük tarihi olmalıdır. Ana veri değişikliği yapan kişi ile faturayı onaylayan kişinin ayrılması [dört göz ilkesi](/sozluk/dort-goz-ilkesi) açısından önemlidir. Otomasyon hatalı ana veriyi görünmez hale getirmemeli, kalite metriği üretmelidir.

## İnsan onayı için iyi ekran nasıl tasarlanır?

İnsan onayı, faturanın PDF'sini açıp tekrar okumak değildir. Ekranın üst kısmında tedarikçi, tutar, vade, sipariş ve risk özeti; orta bölümde çıkarılan alanlar ile kaynak koordinatları; alt bölümde eşleşme farkları, geçmiş benzer faturalar ve önerilen hesap bulunmalıdır. Onaylayan kişi tek bakışta “ne istendiğini, neden beklediğini ve benim hangi kararı verdiğimi” anlamalıdır.

Belirsiz alanlar renkli gösterilebilir ancak renk tek bilgi taşıyıcısı olmamalıdır. Klavye erişimi, ekran okuyucu etiketleri ve mobil onay kısıtları düşünülür. Onay, iade, düzeltme talebi, devretme ve açıklama isteme seçenekleri ayrı olmalıdır. Reddetme nedeni yapılandırılmış seçilebilir alanlarla raporlanırsa model ve süreç ekibi tekrar eden hataları görebilir.

## İstisna yönetimi otomasyonun değeridir

Tam eşleşen faturalar kolaydır; asıl değer istisnayı doğru kuyruğa yönlendirmektir. Fiyat farkı satın alma uzmanına, miktar farkı depo sorumlusuna, vergi bilgisi finans ekibine, sözleşme süresi hukuk veya kategori sahibine, yeni banka hesabı ise güvenlik doğrulamasına gidebilir. Her istisna sınıfının SLA'sı, gerekli kanıtı ve kapatma kodu olmalıdır.

İstisna mesajı “eşleşmedi” gibi belirsiz olmamalıdır. Sistem “faturadaki 120 birim, kabul kaydındaki 100 birimden 20 fazla; tolerans yüzde 5, fark yüzde 20” diyebilmelidir. İnsan kararı sonradan aynı tip faturalar için kural veya ana veri iyileştirmesine dönüşür. Bu nedenle istisna ekranı yalnız operasyon aracı değil, sürekli iyileştirme veri kaynağıdır.

## ERP entegrasyonu ve kayıt sahipliği

ERP finansal kaydın, ödeme koşulunun ve muhasebe belgesinin sahibidir. Otomasyonun görevi ERP'nin yerine geçmek değil, doğrulanmış veriyi doğru API veya entegrasyon kuyruğundan göndermektir. Her kayda kaynak belge kimliği, otomasyon işlem numarası ve onay kanıtı yazılmalıdır. ERP işlemi başarısız olursa fatura “tamamlandı” işaretlenmemeli, yeniden işleme kuyruğunda açık kalmalıdır.

Entegrasyon tasarımında senkron ve asenkron işlemler ayrılır. Basit tedarikçi doğrulaması anlık olabilir; ERP kayıt ve ödeme tetikleme kuyruğa alınabilir. İdempotency anahtarı aynı faturanın iki kez kaydolmasını engeller. Numara çakışması, para birimi yuvarlama, vergi dönemi kapanışı ve ERP bakım penceresi için açık hata kodları hazırlanır. [alfi Platform](/urunler/aile/platform) gateway ve pipeline katmanları bu sözleşmeleri merkezi yönetmeye yardımcı olur.

## E-fatura, e-arşiv ve taranmış belge birlikte nasıl yönetilir?

Elektronik yapısal fatura ile taranmış PDF aynı iş akışının farklı girişleridir. Yapısal XML'de alanların kaynağı makine tarafından doğrulanabilir; PDF'de OCR ve tablo çıkarımı gerekir. Sistem her kanalda aynı kanonik fatura şemasını üretmeli, yalnız kaynak türünü ve doğrulama seviyesini ayrıca tutmalıdır. Böylece finans raporu “PDF sayısı” yerine bütün fatura havuzunu görür.

E-belgenin imza, UUID, senaryo, gönderim ve iptal durumu için ayrı kontroller gerekir. PDF'nin görsel olarak düzgün olması e-belgenin geçerli olduğunu kanıtlamaz. Arşivde orijinal veri, görsel temsil ve işleme kanıtı birlikte saklanır. Saklama süreleri ve erişim politikaları hukuk, finans ve bilgi güvenliğiyle beraber belirlenmelidir.

## Mükerrer, sahte ve olağandışı faturaları yakalama

Mükerrer kontrol yalnız fatura numarasına bakmamalıdır. Tedarikçi, vergi numarası, tarih, toplam, para birimi, sipariş ve belge hash’i birlikte değerlendirilir. Numarası değişmiş ancak görsel ve tutarı aynı olan belge şüpheli olabilir; aynı numara farklı tedarikçiden geldiğinde ise veri kalitesi veya sahtecilik incelemesi açılmalıdır.

Olağandışılık modeli geçmiş davranışı sinyal olarak kullanabilir: alışılmadık tutar, mesai dışı gönderim, yeni banka hesabı, bölünmüş sipariş, tekrar eden yuvarlak tutar veya normalden kısa vade. Bu sinyal otomatik ret anlamına gelmez; risk kuyruğu ve insan incelemesi başlatır. [alfi Insight](/urunler/aile/insight) kalite ve davranış metriklerini görünür kılar; [alfi Boardroom](/urunler/aile/boardroom) yönetim tarafında istisna trendlerini izlemeye yarar.

## KPI: hız kadar doğruluk da ölçülmeli

Fatura başına işlem süresi, ilk bakışta en kolay metriktir. Buna alan çıkarım doğruluğu, otomatik eşleşme oranı, insan devri oranı, ilk seferde doğru hesap kodu, mükerrer yakalama, ERP başarısızlığı ve ödeme gecikmesi eklenmelidir. İnsan onayına giden faturaların oranı tek başına kötü değildir; riskli belgelerin doğru kuyruğa gitmesi daha değerlidir.

Tedarikçi bazlı kalite raporu da önemlidir. Hangi göndericiler okunabilir belge üretmiyor, hangi tedarikçiler sipariş numarası vermiyor, hangi kategori sürekli fiyat farkı yaratıyor? Bu sonuçlar yalnız otomasyon ekibine değil satın alma ve tedarikçi yönetimine aktarılmalıdır. Her KPI için veri tanımı, formül, hedef ve sorumlu olmalıdır.

## Pilot ve geçiş planı

Pilot için en çok belgeyi değil, riski kontrol edilebilir bir tedarikçi grubunu seçin. Aynı kategoride yüksek hacimli, orta karmaşıklıkta ve birkaç istisna üreten belgeler iyi başlangıçtır. İlk fazda otomasyon yalnızca alan çıkarıp insan ekranına öneri sunabilir. İkinci fazda tam eşleşen düşük riskli faturalar ERP'ye otomatik aktarılır; üçüncü fazda istisna sınıfları ve tedarikçi kapsama alanı genişletilir.

Canlıya geçişte paralel çalışma ve geri dönüş planı olmalıdır. Eski süreç bir süre referans olarak tutulur, ancak çift ödeme riski için kayıt sahipliği nettir. Açılışta bekleyen faturalar, açık siparişler, kapanmış mali dönem ve ödeme durumu ayrı senaryolarda test edilir. Eğitim yalnız finans ekibine değil, istisna çözümleyen satın alma, depo ve bütçe sahiplerine de verilir.

## Satın alma kontrol listesi

Bir fatura otomasyon çözümünü değerlendirirken şu maddeleri demo sırasında çalıştırın:

- Taranmış, eğik, çok sayfalı ve tablo içeren fatura okunabiliyor mu?
- Yapısal e-fatura ve PDF aynı kanonik şemaya geliyor mu?
- Her alanın güven skoru ve kaynak bölgesi gösteriliyor mu?
- Tedarikçi, sipariş, mal kabul ve sözleşme ilişkisi nasıl kuruluyor?
- Kısmi teslim, fiyat toleransı, hizmet ve navlun faturası destekleniyor mu?
- Mükerrer belge, yeni banka hesabı ve sıra dışı tutar nasıl işaretleniyor?
- İnsan onayı, devir, iade, açıklama ve dört göz kontrolü var mı?
- ERP API hatası, tekrar deneme ve idempotency nasıl yönetiliyor?
- Orijinal belge, işlem izi, silme ve saklama politikası nasıl uygulanıyor?
- Tedarikçi bazlı kalite ve otomasyon KPI'ları raporlanabiliyor mu?

İyi fatura otomasyonu finans ekibinin kontrolünü azaltmaz; kontrolü daha görünür, daha hızlı ve kanıtlanabilir hale getirir. OCR, model ve entegrasyon ancak bu süreç sözleşmesine hizmet ettiği ölçüde değerlidir. Kurumun hedefi “insansız” bir mutfak değil, doğru faturanın doğru hesaba, doğru zamanda ve doğru kanıtla ulaşması olmalıdır.

## Hizmet faturaları ve kabul kanıtı

Hizmet faturası fiziksel mal gibi depoya girmez; bu nedenle 3-way match kuralı farklı kanıt ister. Sözleşme dönemi, teslim edilen çıktı, iş emri, timesheet, kilometre, metraj veya yetkili kişinin hizmet kabulü faturanın bağlamını oluşturabilir. Model hizmet açıklamasını çıkarabilir, fakat kabulün gerçekten yapıldığını varsaymamalıdır. Kanıt eksikse görev doğru hizmet sahibine açılır.

Abonelik ve dönemsel ödemelerde önceki dönemle karşılaştırma yararlı bir kontrol sağlar. Tutarın, kullanıcı sayısının veya hizmet döneminin beklenmedik değişmesi istisna sinyali üretebilir. Yenileme tarihi yaklaşan sözleşmeler için [alfi Automate](/urunler/aile/automate) görev açabilir; ancak otomatik yenileme veya iptal kararı sözleşme sahibinin onayında kalır. Böylece belge işleme, satın alma ve bütçe yönetimi aynı döngüde görünür.

## Vergi, para birimi ve yuvarlama kontrolleri

Fatura toplamı, satır toplamı, indirim, stopaj, KDV, tevkifat ve kur dönüşümü farklı hesap kuralları taşır. OCR alanları doğru okusa bile birim fiyat ile toplam arasındaki yuvarlama veya vergi dahil/hariç farkı yanlış muhasebe kaydı oluşturabilir. Finansal hesap deterministik bir kural motorunda yapılmalı, model yalnız alan ve bağlam önermelidir.

Çok para birimli faturada belge kuru, ERP kuru, işlem tarihi ve ödeme kuru ayrıştırılır. Yuvarlama toleransı ülke ve süreç politikasına göre tanımlanır; “yakın” değer otomatik kabul edilmez. İnsan ekranı farkın hangi hesaplama adımında oluştuğunu göstermelidir. Bu yaklaşım finans uzmanının belgeyi baştan hesaplamasını değil, gerçekten karar gerektiren farkı incelemesini sağlar.

## Tedarikçi deneyimi ve veri kalitesi

Otomasyon tedarikçiyi yalnız belge gönderen taraf olarak görmemelidir. Hangi alanların zorunlu olduğu, sipariş numarasının nerede bulunacağı, e-fatura veya PDF kanalının nasıl kullanılacağı ve hatanın nasıl düzeltileceği açıkça paylaşılır. Tedarikçiye anlaşılır geri bildirim verilmiyorsa aynı eksik belge tekrar tekrar gelir.

Tedarikçi kalite skoru; okunabilirlik, sipariş referansı, doğru vergi bilgisi, mükerrer oranı, istisna ve düzeltme süresiyle ölçülebilir. [Procure Suite Pro](/urunler/procure-suite-pro) tedarikçi görünümünü satın alma performansıyla birleştirerek kalite görüşmelerini kanıtlı hale getirir. Amaç tedarikçiyi cezalandırmak değil, işlem maliyetini ve ödeme gecikmesini iki taraf için azaltmaktır.

## Fatura dolandırıcılığı ve banka değişikliği

Banka hesabı değişikliği içeren bir fatura, doğru OCR çıktısı olsa bile yüksek riskli kabul edilmelidir. Belgedeki IBAN ile ana verideki IBAN karşılaştırılır; değişiklik talebi bağımsız iletişim kanalıyla doğrulanır. E-postadaki telefon numarasını aramak yeterli değildir; kayıtlı ve güvenilir iletişim bilgisi kullanılmalıdır.

Model sıra dışı tutar, yeni tedarikçi, alışılmadık gönderim zamanı, bölünmüş sipariş ve benzer belge sinyallerini birleştirebilir. Bu sinyal otomatik ret değil, güvenlik ve finans incelemesidir. İnceleme sonucu, yanlış pozitif veya doğrulanmış risk olarak kodlanır; [alfi Guard](/urunler/aile/guard) audit kaydı erişim ve karar kanıtını korur. İlgili ekipler aynı olayı ayrı e-postalarda değil ortak vakada görmelidir.

## Arşiv, mutabakat ve denetim izi

Fatura arşivi orijinal dosya, işlenmiş veri, onay, ERP belge numarası, ödeme durumu ve istisna geçmişini bağlamalıdır. Finans denetimi sırasında “bu tutar neden kaydedildi?” sorusuna tek bir işlem kimliğiyle cevap verilebilmelidir. Model sürümü ve insan düzeltmesi de belge yaşam döngüsünün parçasıdır.

Günlük veya aylık mutabakat otomatik çalıştırılabilir: işlenen belge sayısı ile ERP kayıtları, toplamlar, başarısız aktarım, açık istisna ve ödeme statüsü karşılaştırılır. Fark bulunursa sistem yeni otomatik kayıtları durdurup sorumlu ekibe alarm verir. Mutabakat yapılmadan yüksek otomasyon oranı güvenilirlik göstergesi değildir.

## Rol ve görev tasarımı

Finans, satın alma, depo, bütçe, hukuk ve bilgi güvenliği aynı fatura üzerinde farklı sorumluluk taşır. Onay rolü yalnız departmana göre değil işlem tutarı, kategori, proje ve istisna türüne göre belirlenir. Bir kişinin hem tedarikçi ana verisini değiştirip hem fatura ödemesini onaylaması görev ayrılığına aykırıdır.

Yetki değişiklikleri yaşam döngüsüyle yönetilir. Çalışan izne çıktığında yedek onaylayan, görev değiştiğinde eski kuyruk, işten ayrıldığında açık işler ve erişim anahtarları otomatik ele alınır. Bildirim kanalı değişse de asıl karar uygulamada kaydedilir. Onay bağlantısına sahip olmak tek başına yetki sayılmaz; işlem anında kimlik ve politika yeniden kontrol edilir.

## Maliyet ve ROI hesabı

ROI yalnız çalışanların harcadığı dakika üzerinden hesaplanmamalıdır. Geç ödeme faizi, erken ödeme indirimi, mükerrer ödeme, hatalı hesap kodu, tedarikçi mutabakatı, denetim hazırlığı ve nakit görünürlüğü de hesaba katılır. Otomasyonun lisans ve işletim maliyeti; belge hacmi, sayfa, OCR, model çağrısı, depolama, entegrasyon ve insan istisna süresiyle modellenir.

Pilot öncesi baseline alınır: fatura başına dakika, çevrim süresi, ilk seferde doğru kayıt, açık istisna yaşı ve ödeme gecikmesi. Pilot sonunda aynı formül kullanılır. Otomasyon oranı arttığı halde istisna kuyruğu büyüyor veya yanlış kayıt maliyeti artıyorsa sistem ölçeklenmemelidir. [alfi Insight](/urunler/aile/insight) finans ve satın alma yöneticisine bu dengeyi gösterebilir.

## Canlı işletim ve değişiklik yönetimi

Yeni e-fatura formatı, tedarikçi şablonu, ERP versiyonu veya vergi kuralı geldiğinde iş akışı etkilenir. Değişiklikler önce örnek belgede, sonra gölge ortamda, en son sınırlı canlı grupta test edilir. Model ve kural sürümü birlikte yayınlanmalı, başarısızlıkta önceki sürüme dönüş mümkün olmalıdır.

İşletim ekibi günlük istisna, başarısız aktarım, yeni belge türü, model güveni ve kuyruk yaşını kontrol eder. Ay sonu kapanışında özel çalışma penceresi, kapasite ve manuel geri dönüş planı bulunur. [alfi Platform](/urunler/aile/platform) pipeline ve ops katmanı bu kontrolleri tek ekranda görünür kılabilir; ancak sorumlu finans ekibi değişmez.

## Uygulama olgunluk modeli

Birinci seviye dijital arşiv ve güvenli alımdır. İkinci seviye OCR ve insan doğrulamalı alan çıkarımıdır. Üçüncü seviye sipariş, mal kabul ve fatura eşleştirmedir. Dördüncü seviye düşük riskli tam eşleşmede otomatik ERP kaydı; beşinci seviye tedarikçi kalite, risk sinyali ve nakit planıyla sürekli optimizasyondur. Her seviye bir öncekinden kanıt ister.

Kurum doğrudan beşinci seviyeyi satın alamaz. Ana veri, erişim, onay rolü ve ERP entegrasyonu oturmadan gelişmiş model yalnız karmaşıklığı artırır. Olgunluk değerlendirmesi belge hacmiyle değil süreç standardı, veri sahibi, KPI, istisna disiplini ve geri dönüş planıyla yapılmalıdır. Böylece teknoloji yatırımı gerçek operasyon kapasitesine göre büyür.

## Kapanış ve istisna yaşlandırma

İstisna kuyruğunda yalnız adet değil yaş ve değer izlenmelidir. Vadesi yaklaşan yüksek tutarlı bir belge, yeni açılmış yüz küçük istisnadan önce ele alınabilir. Her açık işin sahibi, son hareketi, beklediği bilgi ve bir sonraki SLA adımı görünür olur. Otomasyon çözülmeyen istisnayı saklamaz; doğru kişiye taşıyıp neden çözülemediğini de raporlar.

Ay sonunda yaşlandırma raporu süreç tasarımına geri beslenir. Sürekli aynı tedarikçi veya aynı maliyet merkezinde oluşan fark, yeni bir model özelliğinden önce sözleşme, ana veri veya satın alma kuralının düzeltilmesini gerektirebilir. Fatura akışının olgunluğu, kaç belgeyi otomatik geçirdiğinden çok hangi istisnayı sistematik olarak azalttığıyla ölçülür.

## Sonuç

Fatura otomasyonu belgeyi hızlı okuyan bir yapay zekâdan ibaret değildir. Güvenli alım, alan kanıtı, 3-way match, ana veri, insan onayı, ERP sahipliği, mutabakat ve denetim izi aynı zincirin parçalarıdır. Bu zincir kurulduğunda finans ekibi her belgeyi yeniden yazmak yerine farkı, riski ve nakit etkisini yönetir; kurum da otomasyonu kontrol kaybı değil, daha görünür bir finans operasyonu olarak kullanır.

## Son doğrulama: belge, kayıt ve ödeme aynı hikâyeyi anlatıyor mu?

Canlıya geçişten önce seçilmiş faturalar üç farklı gözle incelenir: belge alanı doğru mu, iş kuralı doğru mu, ERP ve ödeme sonucu doğru mu? İlk inceleme OCR ve alan çıkarımını, ikinci inceleme sipariş/mal kabul/tolerans ilişkisini, üçüncü inceleme muhasebe ve ödeme mutabakatını kontrol eder. Bu üç katmandan biri başarısızsa otomasyon oranı artırılmaz.

Her tedarikçi ve belge sınıfı için küçük bir kabul paketi saklanır. Paket; normal fatura, kısmi teslim, fiyat farkı, mükerrer, yeni banka bilgisi, düşük kalite tarama ve yanlış tedarikçi senaryolarını içerir. Model veya ERP sürümü değiştiğinde aynı paket yeniden çalışır. Böylece fatura otomasyonu canlıda yalnız görünür değil, tekrar edilebilir bir kalite standardına sahip olur.

## Yönetim için karar özeti

Finans yöneticisi için en anlamlı çıktı, kaç faturanın modele okutulduğu değil, hangi riskin kontrol edildiğidir. Otomatik eşleşen belgeler, açık istisnaların yaşı, tedarikçi kalite trendi, bekleyen ödeme ve ERP mutabakatı aynı görünümde sunulur. Böylece aylık kapanışta teknik model skoru ile gerçek nakit ve uyum sonucu arasında bağ kurulur. Yatırım kararı bu kanıta göre genişletilir veya durdurulur.

## Tedarikçi onboarding'i ve istisna kütüphanesi

Fatura otomasyonunun doğruluğu yalnızca OCR motoruna değil, tedarikçi ana verisinin olgunluğuna da bağlıdır. Yeni bir tedarikçi sisteme alınırken vergi bilgisi, banka hesabı, para birimi, ödeme vadesi, sipariş formatı ve kabul edilen belge kanalı doğrulanır. Aynı tedarikçinin farklı şube veya markaları varsa bunların tek bir tüzel kişiye bağlanıp bağlanmayacağı açıkça belirlenir. Bu çalışma yapılmadan otomatik ödeme eşiğini yükseltmek, yanlış eşleşmeyi hızlandırmaktan başka sonuç doğurmaz.

İstisnalar rastgele notlar olarak değil, tekrar kullanılabilir bir kütüphane olarak tutulmalıdır. “Sipariş var fakat mal kabul eksik”, “kalem açıklaması farklı dilde”, “banka hesabı değişmiş”, “KDV oranı beklenenden farklı”, “kısmi teslim”, “kur farkı” ve “mükerrer belge” gibi durumların her biri için neden, kanıt, sorumlu rol, hedef çözüm süresi ve kapanış kodu tanımlanır. [alfi Automate](/urunler/aile/automate) bu kodları görev ve bildirim akışına dönüştürebilir; [alfi Boardroom](/urunler/aile/boardroom) ise istisna yoğunluğunun tedarikçi ve iş birimi bazında karar gündemine taşınmasına yardımcı olur.

İstisna kütüphanesi model eğitimi için de değer taşır. İnsanların düzelttiği alanlar anonimleştirilir, etiketleme yönergesiyle birlikte saklanır ve yeni sürüm değerlendirmesinde temsil edici örneklem olarak kullanılır. Ancak her düzeltme otomatik olarak modele verilmemelidir; muhasebe politikası değişikliği, tek seferlik anlaşma veya hatalı kullanıcı müdahalesi ayrı işaretlenir. Böylece kurum, “daha fazla veri” ile “daha iyi veri” arasındaki farkı korur.

Yönetim raporunda tedarikçi onboarding süresi, ilk üç ayda manuel düzeltme oranı, istisna başına çözüm süresi, banka değişikliği inceleme oranı ve ödeme öncesi geri dönüş sayısı izlenir. Bu göstergeler birlikte okunduğunda otomasyonun hangi tedarikçi segmentinde güvenli biçimde genişletileceği görünür. Fatura işleme projesi, doğru kurulan bu geri besleme döngüsü sayesinde bir OCR projesinden kurumun satın alma ve finans veri kalitesini yükselten bir operasyon standardına dönüşür.