n8n’deki yapay zeka ajanı başarısız olmadan yanlış fatura verisi ürettiğinde

n8n’de bir yapay zeka ajanıyla yapılan fatura verisi çıkarımında en pahalı hata, hiçbir şeyin kırmızıya dönmediği hatadır. İş akışı sorunsuz çalışır, JSON geçerlidir, her zorunlu alan doludur. Sadece tutar alanında brüt değer yerine net değer yazar, ya da belgede hiçbir yerde bulunmayan bir fatura numarası yer alır. Bunun için bir hata mesajı yoktur: Hata içeriksel bir hatadır, teknik değil.

n8n, değer içeriksel olarak yanlış olduğunda neden bir hata bildirmez?

n8n, yanıtın biçimini kontrol eder, doğruluğunu değil. Structured Output Parser bir JSON şemasını zorunlu kılar, yani alan adlarını, veri tiplerini ve zorunlu alanları. Tutarın faturada yazılı olanla örtüşüp örtüşmediğini bilemez. n8n dokümantasyonu düğümü tam olarak şöyle tanımlar: Alanları "based on a JSON Schema".

Auto-fixing Output Parser bu boşluğu kapatmaz. Dokümantasyona göre, ilki başarısız olduğunda ikinci bir dil modelini çağırır. Bu, bozuk JSON’u onarır, yanlış sayıları değil. Temiz biçimlendirilmiş ama içerik olarak yanlış bir veri seti, her iki düğüm için de başarı sayılır.

Bir yapay zeka ajanı ne sıklıkla içeriksel olarak yanlış fatura alanları üretir?

İyi modeller belge düzeyinde yaklaşık yüzde bir hata oranına sahiptir ve bu yüzde bir kendiliğinden ortaya çıkmaz. Technische Hochschule Brandenburg’da yapılan bir yüksek lisans tezinde Florian Pruß (18 Eylül 2025, danışman Prof. Dr. Emanuel Kitzelmann), LLM çıkarımlarını aifinyo AG’nin gerçekte işlenmiş 10.000 faturasından oluşan bağımsız bir kör veri setine karşı test etti (TH Brandenburg, Yüksek Lisans Tezi). Ölçülen şey Document Accuracy idi: Bir belge yalnızca fatura numarası, fatura tarihi ve tutarın tümü doğruysa doğru kabul edilir.

• Claude 3 Sonnet, Chain-of-Thought ile Few-Shot: yüzde 99,36 Document Accuracy, ölçülen en iyi değer.
• GPT-4.1, Few-Shot: yüzde 99,02.
• Gemma 3 27B-IT, Few-Shot: yüzde 97,61; veri gizliliği açısından kritik senaryolar için açık bir model olarak ilgi çekici.
• Gemma 3 1B-IT: yüzde 24,97. Küçük yerel modeller bu görev için tasarruf seçeneği değil, kullanılamaz durumdadır.
• Karşılaştırma için üretimde kullanılan OCR sistemi: yüzde 87,24.

Yüzde 99,36 sorunun çözüldüğü izlenimini verir. 10.000 faturada bu, en az bir temel alanı yanlış olan ve hepsi sessizce geçen yaklaşık 64 belge demektir. Girdi metninin kalitesi bu noktada model seçimi kadar ağırlık taşır: Aynı strateji aynı modelle, temiz bir PDF metin katmanı üzerinden yüzde 99,77 Overall Accuracy elde ederken, bir Tesseract OCR sürecinde yalnızca yüzde 97,87 elde etti.

Yapay zeka ajanından gelen yanlış fatura verilerini nasıl anlarsınız?

Zaten sahip olduğunuz verilerle çelişkilerden. Tek bir alanın doğruluğu kontrol edilemez, ancak alanların tam bir kümesi kontrol edilebilir, çünkü bir faturanın alanları hesapsal ve içeriksel olarak birbiriyle bağlantılıdır. Her fatura iş akışına altı çapraz kontrol dahil edilmelidir:

• Hesap kontrolü: kalemlerin toplamı artı belirtilen katma değer vergisi, brüt tutarı vermelidir. Net-brüt karışıklığını ve kaybolan kalem satırlarını yakalar.
• Vergi kontrolü: belirtilen katma değer vergisi tutarı, net tutar çarpı vergi oranıyla karşılaştırılır. Yaygın bir oran ortaya çıkmıyorsa belge bir inceleme konusudur.
• Ana veri karşılaştırması: tedarikçi adı, katma değer vergisi kimlik numarası ve IBAN, alacaklı ana verileriyle karşılaştırılır. Bilinen bir tedarikçide değişmiş bir IBAN her zaman bir inceleme konusudur.
• Mükerrer kayıt kontrolü: fatura numarası, alacaklı ve tutar, zaten kaydedilmiş belgelerle karşılaştırılır.
• Tarih tutarlılığı: fatura tarihi ne gelecekte ne de açık muhasebe döneminin dışında olmalı, vade tarihi fatura tarihi artı ödeme vadesine eşit olmalı.
• Sipariş karşılaştırması: tutar ve miktar, belirlenen bir tolerans dahilinde sipariş ve mal girişiyle karşılaştırılır.

Bu kontroller yapay zeka çağının bir icadı değildir, dünün kanun metninde zaten yer almaktadır. GoBD, paragraf 100’de iç kontrol sisteminin bir parçası olarak açıkça "kayıt kontrolleri (hata uyarıları, tutarlılık kontrolleri)", "veri girişinde mutabakat kontrolleri" ve "işleme kontrolleri" ifadelerini kullanır; paragraf 40 ise "içeriksel tutarlılık kontrolleri" talep eder (BMF 28 Kasım 2019 tarihli genelgesi). Bu kontrol adımını bir yapay zeka ajanına geçişte gereksiz görüp kaldıran kişi, önceden var olan bir kontrolü ortadan kaldırmış olur.

Doğrulama katmanına hangi eşik değerleri dahil edilmelidir?

Bir belgenin otomatik olarak geçip geçmeyeceğine iki büyüklük karar verir: kaç çapraz kontrolü geçtiği ve üzerinde ne kadar para olduğu. Tek bir evet-hayır eşiği yerine üç yollu bir trafik ışığı sistemi kendini kanıtlamıştır.

• Yeşil: tüm hesap kontrolleri doğru, alacaklı ve IBAN biliniyor, mükerrer kayıt yok, tutar onay sınırınızın altında. Otomatik olarak devam eder.
• Sarı: yeni bir alacaklı veya aşılmış bir sipariş toleransı gibi tek bir yumuşak sapma. Bir inceleme listesine gider, bir kişi onaylar veya düzeltir.
• Kırmızı: hesap kontrolü tutmuyor, IBAN farklı, mükerrer kayıt şüphesi veya boş bir zorunlu alan var. Asla otomatik olarak kaydedilmez.

Belirleyici olan, trafik ışığının değerlerini nereden aldığıdır. Modelin kendi değerlendirmesinden değil: kendi güven düzeyi sorulan bir dil modeli, ölçülmüş değil, olası bir sayı verir. Eşikler hesaplanabilir kontrollerden, yani aritmetik ve ana veri karşılaştırmasından ortaya çıkmalıdır. Böyle bir eskalasyonun organizasyonel olarak nasıl göründüğü Yapay Zeka Ajanları için Eskalasyon Modeli yazımızda anlatılmaktadır.

Hangi tutardan itibaren bir insanın onay vermesi gerekir?

Yasal bir avro sınırı yoktur. GoBD, kontrolleri ve görevler ayrılığını öngörür; bunların somut biçimi, paragraf 100’e göre açıkça iş faaliyetinin karmaşıklığına ve organizasyon yapısına bağlıdır. Yani sınırı siz kendiniz belirlersiniz ve doğru çıkış noktası mevcut imza yetkisi düzenlemenizdir: şirket içinde 5.000 avrodan itibaren imzayı yönetim kurulu atıyorsa, ajanın bu sınırın üzerinde tek başına karar verecek hiçbir şeyi yoktur.

Hiçbir promptun çözemeyeceği, kendi muhasebemizden bir örnek: NordFlux’un iki müşterisi, § 14 Abs. 2 UStG uyarınca Gutschriftsverfahren (alacak dekontu usulü) ile hesaplaşır, yani faturayı bizim adımıza müşteri düzenler. Belgede "Gutschrift" yazar, fatura düzenleyen NordFlux’tur, gönderen ise hizmet alıcısıdır. Kelimeyi ticari anlamına göre eşleştiren bir çıkarım, bunu negatif işaretli bir fatura düzeltmesine dönüştürür ve gerçek ciroyu eksiye çevirir. Belge temiz okunmuştur, her alan doğrudur, yalnızca anlam tersine dönmüştür. Buna karşı doğrulama katmanında bir kural yardımcı olur: Fatura düzenleyen alanında kendi katma değer vergisi kimlik numaranız yer alıyorsa, başlıkta ne yazdığına bakılmaksızın bu bir satış faturasıdır.

Doğrulama katmanını n8n’de nasıl kurarsınız?

Çıkarım ile hedef sistem arasında ayrı bir bölüm olarak, daha uzun bir prompt olarak değil. Başlangıç için beş yapı taşı yeterlidir:

• Çıkarımı kapsülleyin: ayrı bir alt iş akışı, dönüş kesinlikle Structured Output Parser üzerinden, serbest metin alanı yok.
• Kontrolü Code-Node’da yapın, LLM’de değil: hesap kontrolleri aritmetiktir. Yeniden hesaplama yapan bir dil modeli, ikinci bir hata kaynağı ekler.
• Kontrol sonucunu birlikte taşıyın: geçilen ve tutmayan kuralları veri setinde ayrı bir alan olarak tutun. Bu liste olmadan sonradan hangi kuralın ne sıklıkla devreye girdiği söylenemez.
• Trafik ışığı için Switch-Node: üç yol: yeşil muhasebe sistemine, sarı inceleme listesine, kırmızı bildirimli hata iş akışına.
• Ayrı bir tabloya kaydedin: gelen belge, çıkarılan değerler, kontrol sonucu, karar ve kararı veren kişi. n8n Executions kayıtlarının saklama süresi sınırlıdır ve bir denetim kaydının yerini tutmaz.

GoBD’nin paragraf 100’ü, kontrollerin yalnızca oluşturulmasını ve uygulanmasını değil, aynı zamanda kaydedilmesini de gerektirir; paragraf 102’ye göre kontrol sisteminin tanımı süreç dokümantasyonuna dahil edilmelidir. Dolayısıyla protokolsüz bir doğrulama katmanı amacının yalnızca yarısını yerine getirir. Sürecin genel tabloda nasıl göründüğünü Fatura Girişinin Otomasyonu ve Muhasebe Otomasyonu sayfalarımızda gösteriyoruz.

Sık Sorulan Sorular

İkinci bir dil modeli kontrolü üstlenebilir mi?

Kısmen. Bağımsız ikinci bir çıkarım ve alan alan karşılaştırma, belirsiz belgeleri güvenilir şekilde işaretler. Tek başına hakim olarak uygun değildir: iki model aynı okuma hatasını yapabilir ve kendi çıktısını değerlendiren bir model bağımsız karar vermez. Hesap kontrolleri ve ana veri karşılaştırmaları koda ait olmalıdır.

Daha iyi bir model halüsinasyonlara karşı basitçe yardımcı olmuyor mu?

Ölçülebilir şekilde yardımcı olur, ancak sorunu çözmez. Yüzde 99,36’lık en iyi değer bile 10.000 belgede yaklaşık 64 hatalı belge bırakır ve girdi metninin kalitesi model seçimi kadar ağırlık taşır.

Bu, Output Parser’daki bir hatadan nasıl farklıdır?

Bir parser hatası görünürdür: düğüm başarısız olur, çalıştırma kırmızıya döner, bir hata iş akışı devreye girer. Sessiz içeriksel hata ise daha tehlikeli olan durumdur, çünkü her şey geçerli görünür. Bunun için daha iyi bir hata yönetimi değil, ayrı bir kontrol katmanı gerekir.

Bu, e-fatura ile kendiliğinden çözülmez mi?

Yalnızca kısmen. XRechnung veya ZUGFeRD’de değerleri tahmin ettirmek yerine gömülü XML’den okursunuz. Ancak yapılandırılmış verisi olmayan belgeler yine de girişte kalır ve hesap kontrolü, alacaklı karşılaştırması ile mükerrer kayıt kontrolü formattan bağımsız olarak gereklidir.

Doğrulama katmanını sonradan eklemek ne kadar zahmetlidir?

Teknik kısım daha küçük olanıdır: hesap kontrolleri, tarih tutarlılığı ve mükerrer kayıt kontrolü bir Code-Node’da hızlıca kurulur. Asıl çaba mutabakattadır. Sipariş karşılaştırmasında hangi tolerans geçerli, hangi tutardan itibaren bir insan karar verir, sarı listeyi kim işler. İlk belge otomatik olarak kaydedilmeden önce bunu muhasebeyle netleştirin.