e-Fatura robotunda asıl iş mutabakat: ERP ile e-Belge arasında bir akış

e-Fatura robotu denince çoğu kişinin aklına “XML’i al, ERP’ye yaz” geliyor. O kısım işin kolay yarısı. Zor yarısı, iki sistemin aynı gerçeği gösterip göstermediğini her gün kanıtlamak: e-Belge tarafında olan her fatura ERP’de var mı, ERP’deki her kayıt bir belgeye dayanıyor mu? Bu yazı, bir ERP’yi ulusal e-Fatura altyapısına bağlayan ve mutabakat raporu üreten bir robotun mantığını anlatıyor. Bir de 1 Ocak 2027’nin bu tür akışlara ne getirdiğini.

Neden şimdi

31 Aralık 2025 tarihli Resmî Gazete’de yayımlanan 589 Sıra No.lu VUK Genel Tebliği, e-Fatura ve e-Arşiv uygulamasına dahil olmayan mükelleflerden basit usulde ve işletme hesabı esasında olanlara bir yıl ek süre verdi. TÜRMOB’un sirkülerine göre bu gruptakiler 31 Aralık 2026’ya kadar vergiler dahil 3 bin TL’yi aşmayan faturaları kâğıtta düzenleyebiliyor. 1 Ocak 2027’den itibaren ise tutarına bakılmaksızın bütün faturalarını GİB’in e-Belge portalından düzenlemek zorundalar. Diğer mükellefler için aynı kural 1 Ocak 2026’dan beri geçerli.

Alıcı tarafından bakınca anlamı şu: esnaftan ve küçük tedarikçiden alım yapan bir şirketin borç hesaplarına giren kâğıt fatura kanalı 2027’de büyük ölçüde kapanıyor. Gelen faturaların neredeyse tamamı ya e-Fatura ya e-Arşiv olacak. Bunu ilk radarda kısaca not etmiştim. Buradaki soru daha pratik: elinizdeki robot bu değişikliğe hazır mı?

Bir gelen faturanın ERP kaydına kadar yolu

ERP’yi e-Fatura altyapısına bağlayan entegrasyon ve mutabakat raporu, teslim ettiğimiz robotun omurgası. Kâğıt ve PDF için okuma yolu, insan inceleme adımı ve 2027’ye dönük ayarlar ise benim bu tür akışlar için önerdiğim tasarım.

Sistem

Alım

e-Fatura’lar entegrasyon kanalından, e-Arşiv ve kalan kâğıt faturalar ayrı kanallardan gelir. Hepsi tek bir giriş kuyruğuna, kaynağı etiketlenmiş olarak düşer.

Kural

Kimlik ve mükerrer kontrolü

Elektronik belgede ETTN, tedarikçi vergi numarası ve fatura numarası birlikte anahtar olur. Aynı belge ikinci kez gelirse burada durur; ERP’ye iki kez yazılan bir fatura geri almak için çok iş çıkarır.

Model

Okuma (yalnızca istisna yolu)

Yapısal verisi olmayan belge, yani kâğıt ya da yalnızca PDF olarak gelen fatura, OCR ile okunur. Bu yol ana akış değil; hacmi 2027’den sonra daralmalı ve ayrı ölçülmeli.

Kural

ERP eşleştirme

Fatura satırları sipariş ve mal kabul kayıtlarıyla karşılaştırılır. Tutar, miktar ve vergi tanımlı tolerans içindeyse kayıt hazırlanır; dışındaysa fark gerekçesiyle ayrılır.

İnsan

Fark incelemesi

Eşleşmeyen faturayı borç hesapları uzmanı görür, kararı gerekçesiyle kaydeder. Robot bu kararı tahmin etmeye çalışmaz.

Sistem

Kayıt ve mutabakat raporu

Onaylanan fatura ERP’ye yazılır. Gün sonunda e-Belge tarafında görünen belgelerle ERP’deki kayıtlar karşılaştırılır; iki tarafta da tek başına duran her belge raporda listelenir.

Teslim ettiğimiz şey

Kurduğumuz e-Fatura robotu, bir ERP platformunu ulusal e-fatura altyapısıyla uçtan uca bağlıyor ve mutabakat raporu üretiyor. Bu tür entegrasyonları Logo Tiger 3 ve başka ERP sistemleriyle kurduk. Müşteri adını, hacimleri ve iç detayları paylaşmıyorum. Aşağıdaki tasarım notlarının bir kısmı bu teslimatın omurgasından, bir kısmı bugün benzerini kursam ekleyeceğim şeylerden geliyor. Akıştaki etiket ikisini ayırıyor.

GİB’in açıklaması temel kuralı net koyuyor: e-Fatura uygulamasına kayıtlı iki mükellef birbirine düzenlediği faturaları e-Fatura olarak göndermek ve almak zorunda. Kayıtlı olmayan alıcıya giden fatura ise kâğıt ya da e-Arşiv oluyor. Yani bir şirketin gelen fatura akışı en az iki ayrı biçimden besleniyor. Robotun ilk işi de bu ayrımı kaynağında etiketlemek.

Mutabakat neden ayrı bir iş

Entegrasyon “gelen belgeyi kaydet” der. Mutabakat ise “kaydettiğinin eksiksiz ve tek olduğunu göster” der. İkisi aynı kod içinde yaşayabilir ama farklı soruları cevaplar ve farklı kişiler okur.

Mutabakat raporunda benim görmek istediğim üç liste var:

e-Belge tarafında görünen ama ERP’de karşılığı olmayan faturalar. Bunlar genellikle bekleyen, reddedilmiş ya da robotun bir hata yüzünden atladığı belgelerdir.
ERP’de kaydı olan ama bir elektronik belgeye bağlanamayan faturalar. Elle girilmiş kayıtlar ve kâğıt kanalın kalıntıları burada çıkar.
İki tarafta da olan ama tutarı ya da vergisi uyuşmayan faturalar.

İlk iki liste boşsa robot işini yapıyor demektir. Doluysa bunu ay sonu kapanışında değil, ertesi sabah görmek istersiniz. Bence mutabakat raporunun asıl değeri de bu: hatayı kapanış haftasından günlük işe taşıması.

Kural, model ve insan nerede

Bu akışta kuralın payı yüksek ve öyle kalmalı. Elektronik faturanın yapısal verisi zaten var. Tutarı, vergiyi ve tedarikçiyi bir dil modeline okutmak için bir neden göremiyorum. Mükerrer kontrolü, sipariş ile mal kabul eşleştirmesi ve tolerans kuralları belirlenimci olmalı; denetçi sorduğunda tek cümleyle açıklanabilmeli.

Model, yapısal verisi olmayan belgede devreye girer. 2027’ye kadar bu, küçük tedarikçiden gelen kâğıt fatura demek. Sonrasında da tamamen kaybolacağını sanmıyorum. Elektronik belgenin size hangi biçimde ulaştığı tedarikçinin seçimine bağlı olabiliyor ve bazı faturalar yine yalnızca PDF olarak gelecektir. Bu yüzden okuma yolunu kaldırmazdım; onu istisna yolunun parçası olarak kurardım.

İnsan ise farkın gerekçesini bilen tek taraf. Fiyat farkı anlaşmadan mı geliyor, kısmi teslimattan mı, yanlış siparişten mi? Robottan beklediğim, soruyu doğru kişiye doğru bilgiyle götürmesi. Cevap uydurması değil.

2027 için ayarlanacak dört şey

Hacim tahminini yeniden yapın. Kâğıt fatura okuyan bir OCR akışınız varsa 2027 hacmi büyük olasılıkla düşecek. Lisans ve kapasite planını bu yılın rakamıyla yenilemeyin; tedarikçi listenizi basit usul ve işletme hesabındakiler açısından ayırıp tahmini oradan yapın.
Kanal etiketini zorunlu tutun. Her faturanın hangi kanaldan geldiği kayıtta dursun. Yoksa kâğıt kanalın gerçekten kapanıp kapanmadığını ölçemezsiniz.
e-Arşiv için ayrı bir alım yolu düşünün. e-Arşiv faturanın size hangi biçimde ulaştığı tedarikçiye göre değişebilir. Ocak ayından önce küçük tedarikçilerinizden örnek toplayıp gerçekte ne geldiğine bakın; varsayımla tasarlamayın.
Mutabakat raporuna kanal kırılımı ekleyin. Eşleşmeyen faturaların hangi kanaldan geldiğini görmek, sorunun robotta mı yoksa tedarikçi tarafında mı olduğunu çoğu zaman tek bakışta gösterir.

Ne zaman robot yanlış seçim

Dürüst olmak gerekirse bu iş her zaman robot gerektirmiyor. ERP’nizin kendi e-Fatura modülü ya da özel entegratörünüzün hazır bağlantısı ihtiyacınızı karşılıyorsa önce onu kullanın. GİB de e-Fatura’dan yararlanma yöntemi olarak portal, entegrasyon ve özel entegrasyon seçeneklerini ayrı ayrı tanımlıyor. Robot, bu bağlantının kapatmadığı boşlukta değer üretir: birden fazla ERP, eşleştirme kurallarının özel olduğu süreçler ya da kimsenin sahiplenmediği bir mutabakat işi.

Bir de bakım maliyeti var. Ekran üzerinden çalışan bir robot, ERP’nin her sürüm değişikliğinde kontrol ister. Mümkün olan her adımda ekran yerine servis ya da veri tabanı arayüzünü tercih ederim. Ekranı yalnızca başka yol olmadığında kullanırım.

Kopyalamadan önce

Benzer bir akış kurmayı düşünüyorsanız pazartesi şu soruyu sorun: bugün e-Belge tarafında görünen bir faturanın ERP’de olmadığını kaç gün sonra fark ediyoruz? Cevap “ay sonu kapanışında” ise önceliğiniz entegrasyon değil, mutabakat. 2027 takvimi de bu işe başlamak için iyi bir tarih.