E-Belge Yetki Matrisi: Kim Oluşturur, Kim Gönderir, Kim İptal Talep Eder?
Tek “yönetici” rolü finansal kontrol sağlamaz
E-belge sürecinde hazırlama, doğrulama, gönderme, iptal/itiraz talebi, arşivden dışa aktarma ve kullanıcı yönetimi farklı riskler taşır. Hepsini tek yönetici rolüne vermek, küçük bir kullanıcı hatasının resmî belgeye dönüşmesini kolaylaştırır. Yetki matrisi eylem bazında kurulmalı ve gerçek uygulama izinleriyle eşleşmelidir.
Görev ayrılığı, herkesin farklı kişi olması zorunluluğu değildir. Küçük ekipte aynı çalışan birkaç adımı yapabilir; ancak geri alınması zor işlemler için ikinci onay veya sonradan bağımsız inceleme tasarlanır. Ortak hesap kullanımı, bu telafi kontrolünü de anlamsızlaştırır.
Eylem envanteri
Önce sistemde yapılabilen işler listelenir:
Taslak oluşturma ve satır değiştirme
Müşteri/tedarikçi ana verisi düzenleme
Vergi kodu veya oran seçme
Belgeyi imzalama ve gönderme
Başarısız kaydı yeniden deneme
İptal ya da itiraz talebi başlatma
Gönderilmiş belgeyle ilişkili düzeltme oluşturma
Arşiv görüntüleme ve toplu dışa aktarma
Kullanıcı/rol tanımlama
API anahtarı ve entegrasyon ayarı
Log ve denetim kayıtlarına erişim
Her eylem için kim yapar, kim onaylar, hangi koşulda ikinci onay gerekir ve hangi kanıt saklanır yazılır.
Örnek: satış temsilcisinin geniş yetkisi
Satış temsilcisi hız kazanmak için müşteri kartını, vergi kodunu ve faturayı tek başına düzenleyip gönderme yetkisine sahiptir. Yanlış vergi kimliğiyle fatura gönderir; hatayı fark edince aynı kullanıcı belgeyi arşiv görünümünden kaldırır ve yeni kayıt açar. Olayın ilk hâli yöneticinin raporuna düşmez.
Daha güvenli modelde satış taslağı ve müşteri talebini hazırlar. Ana veri değişikliği doğrulanmış kanal ve ayrı onaydan geçer. Vergi alanı risk kuralına göre finans incelemesine gider. Gönderim yetkisi, kaynak belge ve kontrol tamamlanınca açılır. Arşiv kaydı hiçbir rolde sessizce silinemez.
Risk bazlı onay
Yalnız tutar eşiği kullanılmamalıdır. Yeni müşteri, değişen vergi kimliği, geçmiş tarih, yurt dışı işlem, manuel oran, kapanmış dönem veya daha önce ret alan belge nitel risklerdir. Düşük tutarlı belge de yanlış uyum kuralı nedeniyle ikinci onay gerektirebilir.
Sistem onaylayana sadece toplamı göstermemeli; değişen alanları, kaynağı ve önceki durumu sunmalıdır. “Onayla” düğmesine basıldığı zaman, kullanıcı, cihaz ve işlem sürümü kaydedilir.
Geçici ve acil erişim
İzin, hastalık veya kesinti için verilen yetki başlangıç-bitiş zamanı, kapsam ve gerekçeyle sınırlanır. Süre bitince otomatik kapanır. Acil erişim kullanan kişinin işlemleri olay sonrasında bağımsız örnekleme alınır. Acil rol kalıcı yönetici hesabına dönüşmez.
PIN, ortak parola veya başka çalışanın hesabı yedek yetki değildir. Her kişi kendi kimliğiyle erişmelidir. Ayrılan çalışanın hesabı, API anahtarı, uzak erişimi ve fiziksel cihaz yetkisi birlikte kapatılır.
Periyodik erişim incelemesi
Rol sahipleri insan kaynakları listesiyle karşılaştırılır. Uzun süredir kullanılmayan hesaplar, birden fazla şirkete erişen kullanıcılar ve çakışan kritik yetkiler raporlanır. Yönetici “uygun” işareti atmak yerine gerekli/gereksiz kararını görev gerekçesiyle verir.
Uygulama ekranındaki rol adı yeterli değildir. Gerçek API izinleri ve doğrudan veri tabanı erişimleri de kapsamda olmalıdır. Teknik yönetici mali kayıt değiştirme yetkisine sahip olmamalıdır.
Denetim izi
Yetki talebi, onayı, yürürlük zamanı, kullanım olayları ve kapanış saklanır. Log yöneticiler tarafından değiştirilemiyorsa güvenilirlik artar. Şüpheli olayda ilk log kopyası ve bütünlük bilgisi korunur.
Küçük işletmede görev ayrılığı mümkün mü?
Tam ayrılık zor olabilir; kritik işlemlerde ikinci onay veya düzenli bağımsız örneklem kullanılabilir.
Yönetici rolü her işlemi yapmalı mı?
Hayır. Yönetim ihtiyacı, mali belge değiştirme veya log silme yetkisini otomatik gerektirmez.
Geçici yetki nasıl kapatılır?
Bitiş tarihiyle otomatik kapanmalı ve kullanılan işlemler sonradan incelenmelidir.
API ve servis hesapları
İnsan kullanıcılar kadar entegrasyon hesapları da matrise dâhildir. Bir API anahtarının hangi şirket, belge türü ve eylemlere eriştiği bilinmelidir. Okuma için kullanılan anahtar gönderme veya iptal yetkisi taşımamalıdır. Anahtarlar kod deposuna, destek kaydına ya da ekran görüntüsüne açık biçimde konmamalıdır.
Anahtar yenileme sırasında eski ve yeni erişimin çakışma süresi sınırlandırılır. Başarısız kullanım, farklı IP veya olağandışı toplu dışa aktarma güvenlik alarmı doğurabilir. Servis hesabının yaptığı mali işlem, ilgili ticari kullanıcı ve kaynak işleme geri bağlanmalıdır.
Onay kuralı testi
Test ortamında düşük tutar, yüksek tutar, yeni müşteri, geçmiş dönem, manuel vergi kodu, ret sonrası yeniden gönderim ve toplu arşiv indirme senaryoları denenir. Beklenen rolün işlemi yapabildiği kadar, yetkisiz rolün yapamadığı da kanıtlanır. Kullanıcı arayüzünde düğmenin gizli olması yeterli değildir; API düzeyinde yetki kontrolü gerekir.
Matriste değişiklik yapıldıktan sonra regresyon testi tekrarlanır. Bir rolün yeni özelliğe yanlışlıkla geniş yetki alması önlenir. Bulgular, ekran görüntüsü yanında istek/cevap ve denetim günlüğüyle saklanır.
Üç ayda bir seçilen kullanıcılar üzerinden rol, fiilî görev, son işlem ve yönetici onayı karşılaştırılır; kullanılmayan ayrıcalıklar gerekçesiz biçimde açık bırakılmaz.
Bu yazı genel iç kontrol rehberidir. Yetki matrisini gerçek iş akışı, GİB yükümlülükleri ve bilgi güvenliği riskleriyle birlikte mali müşaviriniz ve teknik ekibinizle tasarlayın.
Kaynaklar
Mehmet Hakkı Yuvanç
FiscusAI ekibi
