DEV Community: Mehmet Hakkı Yuvanç

Finansal Yetki Matrisi Nasıl Kurulur? KOBİ’ler İçin Uygulanabilir Kontrol Modeli

Mehmet Hakkı Yuvanç — Mon, 12 Oct 2026 10:13:57 +0000

KOBİ’lerde finansal risk yalnızca yanlış hesaplamadan doğmaz. Aynı kişinin talep oluşturabildiği, onay verebildiği, ödemeyi gerçekleştirebildiği ve kaydı kesinleştirebildiği bir süreç de başlı başına risktir.

Finansal yetki matrisi; bir işlemin kim tarafından talep edileceğini, kontrol edileceğini, onaylanacağını, uygulanacağını ve sonradan kimin izleyeceğini açıkça tanımlar. Amaç bürokrasiyi artırmak değil, kritik finansal kararların tek kişiye ve görünmez istisnalara bağlı kalmasını önlemektir.

Bu yazı, FISCUS AI’ın kapsamlı rehberinin uygulamaya dönük bir özetidir. Ayrıntılı kontrol listesi için orijinal finansal yetki matrisi rehberini inceleyebilirsiniz.

Önce işlemi, sonra rolü tanımlayın

İlk adım unvanları listelemek değil, finansal süreci baştan sona haritalamaktır. Örneğin bir tedarikçi ödemesi şu adımlardan geçebilir:

İş ihtiyacının ve satın alma talebinin oluşturulması
Tedarikçi ve belge bilgilerinin kontrolü
Bütçe ve ödeme onayı
Banka talimatının hazırlanması
Ödemenin serbest bırakılması
Muhasebe kaydının kesinleştirilmesi
Banka ve cari hesap mutabakatı
İstisnaların raporlanması

Her adımda hangi veri veya finansal varlığın değiştiğini yazın. Sadece “finans ekibi” demek yeterli değildir; hazırlayan, kontrol eden, onaylayan ve uygulayan rolleri ayırmak gerekir.

Beş temel sorumluluk

Pratik bir matriste beş rol bulunur:

Talep eden: İş ihtiyacını ve gerekçesini açıklar.
Kontrol eden: Belgeyi, bütçeyi, taraf bilgisini ve politika uyumunu inceler.
Onaylayan: Kurumsal yetkiyi kullanarak kararı verir.
Uygulayan: Banka talimatını veya kesin muhasebe kaydını gerçekleştirir.
İzleyen: Mutabakat, örneklem ve sonradan kontrol yapar.

Küçük işletmelerde bu görevlerin her biri için ayrı bir çalışan bulunmayabilir. Böyle bir durumda ayrım tamamen terk edilmemeli; bağımsız yönetici incelemesi, günlük banka bildirimi veya periyodik örneklem gibi telafi edici kontroller kullanılmalıdır.

Tutar limiti tek başına yeterli değildir

Yetki matrisi yalnızca “10.000 TL’ye kadar” gibi parasal eşiklerden oluşmamalıdır. Risk; işlem türüne, şirkete, şubeye, banka hesabına, para birimine, tedarikçinin durumuna ve aciliyete göre değişir.

Yeni açılmış bir tedarikçiye yapılan ilk ödeme ile uzun süredir çalışılan bir tedarikçinin olağan ödemesi aynı riskte değildir. Banka hesap bilgisi değişmişse ikinci kanal doğrulaması ve ek onay gerekebilir. Aynı talebin küçük parçalara bölünerek limit altında tutulması da sistem tarafından izlenmelidir.

Temel görev çakışmaları

Her şirket kendi risk değerlendirmesini yapmalıdır; ancak aşağıdaki kombinasyonlar özellikle incelenmelidir:

Talep eden kişi kendi talebini tek başına onaylamamalıdır.
Tedarikçi banka bilgisini değiştiren kişi ilk ödemeyi tek başına serbest bırakmamalıdır.
Banka talimatını hazırlayan kişi mümkünse tek başına göndermemelidir.
Muhasebe kaydını yapan kişi mutabakat farkını bağımsız inceleyen tek kişi olmamalıdır.

Sistem yalnızca çakışmayı raporlamamalı; işlem anında uygun uyarı, ek onay veya engel üretmelidir. Uyarı bir suç kanıtı değil, insan incelemesini başlatan bir kontrol sinyalidir.

Geçici yetkiler görünmez olmamalı

İzin, seyahat veya iş sürekliliği için vekâlet gerekebilir. Bu yetkide başlangıç ve bitiş zamanı, kapsam, gerekçe, veren ve kabul eden kişi kaydedilmelidir. Süre dolduğunda erişim otomatik olarak sonlanmalıdır.

Acil erişim kullanılmışsa gerçekleştirilen işlemler bağımsız bir kişi tarafından belirli süre içinde incelenmelidir. “Acil durum” kalıcı ve denetimsiz bir arka kapıya dönüşmemelidir.

Sistem ile banka yetkilerini eşleştirin

Kâğıt üzerindeki matris ile gerçek sistem yetkileri farklıysa kontrol çalışmıyor demektir. Banka portalı, muhasebe uygulaması, satın alma aracı ve kimlik sağlayıcısındaki roller düzenli olarak karşılaştırılmalıdır.

Ortak kullanıcı hesapları kimin hangi işlemi yaptığını belirsizleştirir. Bireysel kullanıcı, çok faktörlü doğrulama ve dar kapsamlı servis hesapları tercih edilmelidir. Yetki değişikliklerinin kanıtı saklanmalı ve geçmiş işlem kayıtları geriye dönük olarak değiştirilmemelidir.

Denetim izi neyi göstermeli?

Sağlıklı bir sistem şu soruları yanıtlayabilmelidir:

İşlemi kim talep etti?
Kim kontrol etti ve onayladı?
Hangi veri değişti?
İşlem hangi kanal üzerinden uygulandı?
Mutabakatı kim yaptı?
Ret, geri çekme veya istisna varsa gerekçesi neydi?

Onay zinciri sonradan sessizce düzenlenememelidir. Limit değişiklikleri yürürlük tarihiyle sürümlenmeli; geçmiş işlemler yeni limite göre yeniden etiketlenmemelidir.

FISCUS AI yaklaşımı

FISCUS AI, KOBİ finans operasyonlarında insan onayı, açıklanabilir karar desteği ve denetim izini aynı çalışma katmanında ele almayı amaçlar. AI önerileri kesin muhasebe kaydı değildir; kritik işlemler kontrollü durum geçişleri ve yetki sınırları içinde ilerlemelidir.

Tam rehber, kapsam notları ve kaynaklar için: Finansal Yetki Matrisi: Talep, Onay, Ödeme ve Kayıt Rollerini Ayırmak

Bu içerik genel iç kontrol yaklaşımıdır; hukuki temsil yetkisi, banka sözleşmesi veya belirli bir ödeme kararı hakkında görüş değildir. Şirketin imza ve yetki düzeni hukukçu ve mali müşavirle doğrulanmalıdır.

How to Test Financial Automation Without Real Customer Data

Mehmet Hakkı Yuvanç — Mon, 12 Oct 2026 07:52:39 +0000

Financial automation fails in ways that ordinary CRUD tests rarely cover. A duplicated callback can post the same effect twice. A stale approval can commit a superseded suggestion. A frontend may display “completed” while the provider is still processing the request.

Testing these systems with production exports creates a second problem: financial and customer data should not be copied into public demos, sample repositories, or ad-hoc development environments.

A safer approach is to build synthetic state fixtures around the workflow rules you need to prove.

1. Design fixtures around decisions, not random rows

Randomly generated amounts and descriptions may help with volume tests, but they do not prove domain behavior. Each fixture should represent a question the system must answer.

Examples:

Can a draft move to review?
Can a rejected suggestion be posted?
What happens when the same provider event arrives twice?
Does a missing evidence reference block approval?
Is a correction recorded without erasing the previous state?

A compact JSONL case can describe both the starting state and the expected result:

{
  "case_id": "duplicate_callback_001",
  "entity_type": "synthetic_collection",
  "initial_state": "provider_pending",
  "event": "provider.confirmed",
  "idempotency_key": "synthetic-event-001",
  "expected_state": "confirmed",
  "expected_audit_events": 1,
  "contains_real_customer_data": false
}

The identifiers and values above are synthetic. They describe behavior, not a real transaction.

2. Keep a transition matrix beside the data

The dataset is more useful when the allowed and forbidden transitions are explicit.

From	Event	Expected result
draft	submit_for_review	review_required
review_required	approve	approved
approved	post	posted
rejected	post	rejected with domain error
posted	approve	posted with idempotent response

The negative rows matter as much as the happy path. A finance-critical service should fail clearly when a transition is invalid; it should not silently coerce the state or pretend that the operation succeeded.

3. Test retries as first-class scenarios

External operations are retried in normal production conditions. Your fixtures should include:

the first valid delivery,
an identical retry,
a retry with the same key but conflicting payload,
an out-of-order event,
a provider timeout followed by a later confirmation.

For an identical retry, assert more than the HTTP status. Verify that:

the financial effect exists once,
the stored provider reference is stable,
no duplicate audit event was appended,
the response is consistent with the first successful application.

4. Assert auditability, not only final state

A test that checks only status === "posted" misses important failure modes. Also assert the transition history:

initial state
  -> requested event
  -> guard evaluation
  -> authorized actor or policy
  -> resulting state
  -> audit event

For corrections and reversals, preserve the original event and add a compensating action. The fixture should make the expected history reconstructible.

5. Test API and UI semantics together

A backend may correctly return provider_pending while the interface labels it “Completed.” That is still a product defect.

Use the same fixture vocabulary across layers:

API contract tests verify status and error semantics.
Service tests verify guards, idempotency, and audit events.
UI smoke tests verify the exact user-visible label and allowed actions.

Avoid optimistic finance messaging that hides uncertainty. If the provider state is unknown, the interface should say so.

6. Version the fixture contract

Synthetic data is still an interface. Give the schema a version and record why fields change.

A practical fixture repository can include:

schema_version,
JSONL for event-oriented cases,
CSV for inspection and simple tooling,
a README defining every field,
a license,
checksums or release tags for reproducibility.

When a workflow rule changes, add a new case or version instead of silently rewriting the evidence used by earlier tests.

A public reference set

We published a small, fully synthetic reference set for auditable, human-in-the-loop financial workflow states: FISCUS AI Financial Workflow State Fixtures.

It is intended for testing and demonstration, not as accounting data and not as a substitute for domain-specific validation. The fixtures contain no real customer transactions.

At FISCUS AI, we use this state-first perspective to reason about controlled automation for Turkish SME financial operations.

This article provides general technical information and is not accounting, tax, legal, or investment advice.

When Should an AI Suggestion Become a Financial Record?

Mehmet Hakkı Yuvanç — Sat, 05 Sep 2026 19:22:25 +0000

AI can classify an expense, propose a match between a bank transaction and an invoice, or flag an unusual cash-flow pattern. None of those outputs should automatically become accounting truth.

That boundary matters more than raw model accuracy.

A model output is probabilistic. A financial record changes operational state: balances, collections, reporting, tax workflows, and sometimes legally significant documents. Treating both as the same object creates a dangerous failure mode — a plausible prediction silently becoming a committed fact.

1. Store the suggestion as its own artifact

An AI suggestion should be immutable and traceable. At minimum, keep:

the model and prompt/policy version,
creation time and actor,
source records used,
confidence and human-readable reason codes,
the proposed action,
whether it was accepted, rejected, expired, or superseded.

This makes the question “Why did the system recommend this?” answerable later. It also gives you useful rejected examples without rewriting financial history.

2. Commit through domain rules, not model confidence

A high confidence score is not authorization. Before a suggestion changes financial state, the application should still verify:

tenant and user permissions,
the current state of every affected record,
amount, currency, tax, and document constraints,
whether another process already completed the action,
the required approval policy for that risk level.

The final write should be an explicit domain transition with an idempotency key and an audit event. This protects the system from retries, stale suggestions, and concurrent updates.

3. Use risk-based automation

Not every recommendation needs the same control.

A low-risk category suggestion might be saved as a draft. A bank reconciliation proposal may require a finance user to confirm it. A transition that affects a tax document, payment, ledger entry, or e-document status should usually require stronger validation and explicit approval.

A useful policy considers:

financial amount,
reversibility,
document type,
confidence,
downstream impact,
regulatory significance.

The goal is controlled autonomy: automate more when the impact is limited and observable, and slow down when a mistake would propagate.

4. Reverse with compensating actions

“Undo” should not mean deleting the evidence.

If a user accepts the wrong transaction match, preserve the original suggestion, the acceptance event, the correction reason, and the new state. Create a compensating action that reverses the effect. That gives operators a truthful timeline and keeps the audit trail reconstructible.

5. Explain the evidence, not only the percentage

“92% confidence” is rarely enough for a finance user. Better explanations look like:

amount exactly matches the open invoice,
transaction date is within the expected window,
reference text contains the invoice number,
customer and bank-account ownership agree.

Concrete evidence turns human approval into a real control instead of a ceremonial click.

A practical architecture rule

Keep three layers separate:

Suggestion: what the model thinks should happen.
Decision: what policy and an authorized person allow.
Record: what the financial system actually committed.

Each layer should have its own identifier, timestamps, status, and audit events.

This is the approach we are developing at FISCUS AI, an AI-assisted financial operating system for SMEs in Türkiye. Our focus is to make automation explainable, reversible, and consistent with the underlying financial state. We also describe the product's AI-accounting approach at AI-assisted accounting for SMEs.

The important question is not “Can the model make this decision?” It is: What evidence, policy, and audit trail must exist before the system is allowed to commit it?