İşlem Denetimi & Mutabakat - Mali Denetim & Fintech Operasyonları

Bu grup ne yapar

İşlem Denetimi & Mutabakat, Mali Denetim & Fintech Operasyonları eklentisinin işlemsel bütünlük katmanıdır: bir 3 yönlü fatura eşleştirme defteri, çok kaynaklı bir banka/ödeme geçidi/POS/ERP mutabakat defteri, bir dolandırıcılık/anomali triyaj defteri ve bir hesap planı satır varyans defteri. Dört ekranın tümü, Genel Bakış sayfasında açıklanan aynı doğrudan kayıt bazlı iki aşamalı hibrit motoru kullanır (Aşama 1 embedding altyapısı, UI'ya bağlı değil; Aşama 2 yapay-zeka-motoru-yönlendirmeli sentez).

Fatura Eşleştirme Denetimi

→

Çok Kaynaklı Denetim & Mutabakat

→

Dolandırıcılık Tespiti & Anomali Denetimi

→

Defter Varyans Denetimi

1. Fatura Eşleştirme Denetimi

Amaç: Bir 3 yönlü eşleştirme denetim defteri — bir tedarikçi faturasını satın alma siparişi (PO) ve mal kabul (GRN) tutarlarıyla karşılaştırır, böylece AP ekipleri ödeme onayı vermeden önce eşleşme riskini görebilir.

Defter sütunları / temel alanlar

ID formatı INV-YYYY-XXXX
matchId, invoiceNo, vendorName, poReference, invoiceAmount, poGrnAmount, currency
matchStatus — fully_matched / price_discrepancy / quantity_mismatch / unlinked_po
countryCode, auditDate, aiDiscrepancyBreakdown

Gösterge

3-Way Match Ratio Meter — toplam kayıt sayısı içinde tam eşleşen kayıtların yuvarlanmış yüzdesi. Standart durum-sayım deseni. Bar rengi: ≥%80 yeşil, %50–79 sarı, altı kırmızı.

Temel eylemler

Yeni Kayıt — kayıt modalını açar.
AI Analiz Et — fatura eşleştirme denetimini çalıştırır, bir sapma açıklaması ile bir güven skoru üretir; fatura numarası veya tedarikçi adı boşken devre dışıdır.
Onayla / Ödeme İçin Onayla (satır aksiyonu) — yalnızca kaydın kendi eşleşme durumunu tam eşleşti olarak günceller; zaten tam eşleşmişse devre dışıdır.
Silme — kalıcıdır, satır içi onay ile.

Bilinen sınırlama

Onayla, gerçek bir accounts-payable defterine dokunmaz. Uygulamada gerçek tedarikçi faturalarını içeren gerçek bir Tedarikçi Borçları modülü mevcuttur, ancak bu kayıtlarla bu ekranın fatura eşleştirme kayıtları arasında bir link/lookup yoktur. Onayla, yalnızca bu eklentinin kendi kaydını günceller.

2. Çok Kaynaklı Denetim & Mutabakat

Amaç: Kod içinde Bank Reconciliation olarak adlandırılır. Bir banka/ödeme geçidi/POS/ERP ekstresini şirketin iç defter bakiyesiyle karşılaştırır — eşleşti, kapanma bekliyor veya açıklanamayan bir fark.

Defter sütunları / temel alanlar

ID formatı REC-YYYY-XXXX
reconciliationId, statementReference, channel (bank / payment_gateway / pos / erp_internal)
statementBalance, internalBookBalance, currency
status — matched / unmatched_variance / pending_clearance
countryCode, auditDate, aiVarianceBreakdown

Gösterge

Reconciliation Match Ratio Gauge — toplam içinde eşleşti olarak işaretlenen kayıtların yüzdesi. Bar rengi: ≥%80 yeşil, %40–79 sarı, altı kırmızı.

Temel eylemler

Yeni Kayıt, AI Analiz Et (mutabakat denetimini çalıştırır, bir varyans açıklaması ile isteğe bağlı önerilen bir düzeltme üretir; ekstre referansı boşken devre dışıdır).
Ayarla / Varyansı Düzelt (satır aksiyonu, satır içi mini-form: tutar + gerekçe) — bir düzeltme notu ekler ve düzeltme tutarı kalan farkı kapatıyorsa durumu eşleşti'ye çevirir.
Silme — kalıcıdır.

Bilinen sınırlama

Ayarla, gerçek bir genel muhasebe defterine postlamaz. Bugün uygulamada hiçbir yerde bir journal-entry-posting sistemi yoktur. Ayarla, yalnızca bir not ekler ve kendi kaydının durumunu koşullu olarak günceller.

3. Dolandırıcılık Tespiti & Anomali Denetimi

Amaç: Bir dolandırıcılık triyaj defteri — hesap/varlık başına şüpheli işlem örüntülerini (hız artışları, yapılandırma/structuring, coğrafya/IP uyuşmazlıkları) işaretler, her biri bir risk skoru, risk seviyesi ve denetim kararı taşır.

Defter sütunları / temel alanlar

ID formatı FRD-YYYY-XXXX
auditId, accountRef, transactionVolume, currency
riskScorePct (0–100), anomalyType (velocity_spike / structuring / geo_ip_mismatch)
riskLevel (critical / high / medium), auditAction (frozen / under_review / cleared)
triggerTimestamp, countryCode, aiPatternAnalysis

Gösterge

Portfolio Anomaly Severity Meter — toplam içinde kritik veya yüksek risk seviyesindeki kayıtların yüzdesi. Ters mantıklı bar (yüksek olması kötü): ≥%60 kırmızı, %30–59 sarı, altı yeşil. Satır seviyesindeki risk skoru barları aynı eşikleri kayıt başına bağımsız olarak kullanır.

Temel eylemler

Yeni Kayıt, AI Analiz Et (dolandırıcılık/anomali denetimini çalıştırır, bir örüntü analizi ile isteğe bağlı bir güven skoru üretir; hesap/varlık referansı boşken devre dışıdır).
Hesabı Dondur / Varlıkları Dondur (satır aksiyonu, satır içi mini-form: gerekçe) — denetim kararını donduruldu olarak ayarlar ve bir "Frozen: ..." notu ekler; zaten donmuşsa devre dışıdır.
Silme — kalıcıdır.

Bilinen sınırlama

Dondur, gerçek bir hesabı kilitlemez veya gerçek bir güvenlik ekibine bildirim göndermez. Bugün uygulamada hiçbir yerde ayrı bir hesap-dondurma/güvenlik-uyarı sistemi yoktur. Aksiyon, yalnızca bu kaydın kendi denetim-aksiyonu alanını günceller.

4. Defter Varyans Denetimi

Amaç: Bu gruptaki son ekran. Bir hesap planı satırının beklenen bakiyesi (mizan) ile gerçek defter bakiyesi arasındaki farkı takip eder — açıklanamıyor, incelemede veya mutabık.

Defter sütunları / temel alanlar

ID formatı VAR-YYYY-XXXX
auditId, accountCode, accountTitle, expectedBalance, actualBalance, currency
varianceSeverity (high / medium / low), auditStatus (unexplained_variance / under_review / reconciled)
financialPeriod, countryCode, aiRootCauseAnalysis

Gösterge

Balance Sheet Integrity Index — toplam içinde mutabık olarak işaretlenen kayıtların yüzdesi. Bar rengi: ≥%80 yeşil, %40–79 sarı, altı kırmızı.

Temel eylemler

Yeni Kayıt, AI Analiz Et (defter varyans denetimini çalıştırır, bir kök neden analizi ile isteğe bağlı bir güven skoru üretir; hesap kodu/başlığı boşken devre dışıdır).
Düzeltme Kaydı Postla (satır aksiyonu, satır içi mini-form: tutar + borç hesabı + alacak hesabı + gerekçe) — denetim durumunu mutabık olarak ayarlar ve notlara düzeltme detaylarını ekler; zaten mutabıksa devre dışıdır.
Silme — kalıcıdır.

Bilinen sınırlama

Düzeltme Kaydı Postla, gerçek bir çift kayıtlı journal entry postlamaz. Finans modülünde gerçek bir Journal Entries ekranı vardır, ancak o modülün servis katmanı dışa açık bir journal-posting fonksiyonu sunmaz ve bu ekranın defter varyans kayıtlarıyla gerçek bir genel defter kaydı arasında bir link/lookup da yoktur. Aksiyon, yalnızca bu kaydın kendi durumunu ve notlarını günceller.

Mimari not: embedding katmanı mevcut ama UI'ya bağlı değil

Bu gruptaki 4 ekranın tümü, eklenti genelindeki iki aşamalı hibrit motoru izler. Aşama 1 (embedding) semantik-arama altyapısı sırasıyla Banka Mutabakatı, Dolandırıcılık Tespiti ve Fatura Eşleştirme için mevcuttur (Defter Varyans Denetimi'nde ise özel bir semantik arama hiç yoktur) — ancak 4 ekranın hiçbiri henüz bunu kullanmıyor. Kullanıcılar formu doldurmaktan doğrudan "AI Analiz Et"e basmaya geçer; bu, önce bir semantik-arama adımı olmadan doğrudan Aşama 2'yi (yapay-zeka-motoru-yönlendirmeli sentez) tetikler. Tam iki aşamalı mimari için Genel Bakış sayfasına bakın.

Bu bölümdeki sayfalar

Sık Sorulan Sorular

Fatura Eşleştirme Denetimi'ndeki Onayla gerçekten tedarikçiye ödeme yapar mı?

Hayır — yalnızca bu kaydın kendi eşleşme durumunu tam eşleşti olarak günceller. Gerçek accounts-payable defteri ve onun tedarikçi fatura kayıtlarıyla bir bağlantı yoktur.

Çok Kaynaklı Denetim & Mutabakat'taki Ayarla bir genel deftere postlar mı?

Hayır — bu kod tabanında hiçbir yerde bir genel-muhasebe-defteri / journal-posting sistemi yoktur. Aksiyon yalnızca bir düzeltme notu ekler ve tutar farkı kapatıyorsa kaydın kendi durumunu eşleşti'ye çevirir.

Dolandırıcılık Tespiti'ndeki Hesabı Dondur gerçekten hesabı kilitliyor mu?

Hayır — bugün uygulamada bir hesap-dondurma veya güvenlik-uyarı sistemi yoktur. Aksiyon yalnızca bu kaydın kendi denetim-aksiyonu alanını donduruldu olarak günceller.

Embedding/semantik-arama katmanı bu 4 ekranda herhangi bir yerde kullanılıyor mu?

Hayır — arka plan altyapısı olarak mevcuttur ama henüz 4 ekranın hiçbiri tarafından kullanılmıyor. Kullanıcılar doğrudan formdan AI Analiz Et butonuna geçer, bu da yalnızca Aşama 2 sentezini tetikler.

Ollama yapay zeka motoru bu ekranlar için hiç sunucuyu çağırıyor mu?

Hayır — seçilen yapay zeka motoru Ollama, yerel-LLM veya web-LLM olduğunda, 4 ekranın tümü analizini doğrudan tarayıcıdan çalıştırır ve asla sunucuya gitmez. Yalnızca yerel-CLI ve API sunucuya yönlenir.