Satın Alma Onay Akışları: Hız-Kontrol Dengesini Kurmak (2026)
Onay Akışı Temelleri ve Tasarım İlkeleri

Onay akışı iyi kurgulandığında, süreç kendiliğinden işler
Bir satın alma talebi (PR) açıldığı andan siparişe (PO) dönüştüğü ana kadar hangi adımlardan geçer, nerede kim onay verir? Onay akışı tam olarak bunu tarif eder. İşin püf noktası şu: aynı akış hem harcamayı kontrol altında tutmalı hem de kimseyi günlerce onay bekletmemeli. Bu ikisini dengeleyemeyen tasarımlar ya bürokrasiye ya da kontrolsüzlüğe kayar.
Temel Tasarım İlkeleri
- Görev ayrılığı (Segregation of Duties): Talebi açan, onaylayan ve siparişi veren aynı kişi olmamalıdır. Bu üçünün tek elde toplandığı yer, denetimin ilk baktığı yerdir.
- En az yetki prensibi: Herkes yalnızca kendi işini yapabilecek kadar yetki taşımalı, bir gram fazlası değil.
- İzlenebilirlik: Her adım kim tarafından, ne zaman yapılmış kayıt altında olmalı.
- İstisnai durum yönetimi: Acil ihtiyaçlar için bir bypass mekanizması gerekir; ama bu tür işlemler sonradan mutlaka onaya düşmeli, öylece bırakılmamalı.
Akış Mimarisi Katmanları
Pratikte tipik bir satın alma onay akışı dört katmandan oluşur:
- Talep Katmanı: İhtiyaç sahibi departman talebi oluşturur.
- Bütçe Kontrolü: Talebin bütçeyle uyumu kontrol edilir.
- Hiyerarşik Onay: Tutar ve kategoriye göre yetkili kişiler onaylar.
- Satın Alma Operasyonu: Onaylanan talep siparişe dönüşür.
Her katmanda farklı roller ve sorumluluklar devreye girer. Katmanlar arası geçişleri ise iş kuralları yönetir; talebin bir sonraki adıma geçip geçmeyeceğine bu kurallar karar verir.
Onay Matrisi Tasarımı: Kimler, Hangi Koşullarda?

Matris, kağıt üzerindeki organizasyon şemasıyla örtüşmediği anda sorun çıkarır
Onay matrisi, hangi koşulda kimin onay vereceğini belirleyen kurallar bütünüdür. Tasarlarken birkaç parametreyi birlikte düşünmek gerekir:
Matris Parametreleri
1. Tutar Aralıkları
En temel parametre satın alma tutarıdır. Tutar büyüdükçe onay yetkisi de üst kademelere taşınır. Örnek bir yaklaşım şöyle olabilir:
- Düşük tutar: Departman yöneticisi tek başına onaylar.
- Orta tutar: Departman yöneticisinin yanına finans onayı eklenir.
- Yüksek tutar: Genel müdür ya da yönetim kurulu devreye girer.
2. Satın Alma Kategorisi
Her kategori kendi risk profilini taşır:
- Doğrudan üretim malzemesi: Üretim planlama ve satın alma birlikte onaylar.
- Dolaylı malzeme (MRO): Standart hiyerarşi uygulanır.
- Hizmet alımları: İlgili departmanın yanında çoğu zaman hukuk görüşü de gerekir.
- Yatırım harcamaları (CAPEX): Üst yönetim ve finans birlikte değerlendirir.
3. Maliyet Merkezi / Departman
Her departmanın onay zinciri aynı olmak zorunda değil. Üretimin akışıyla pazarlamanın akışı pekala ayrışabilir.
4. Tedarikçi Tipi
Onaylı tedarikçi listesindeki firmalardan yapılan alımlar daha hızlı geçerken, ilk kez çalışılan bir tedarikçi ek değerlendirme gerektirebilir.
Matris Örneği
Aşağıdaki örnek, tutar ve kategoriye göre onay hiyerarşisinin nasıl kurulabileceğini gösteriyor (değerler temsilidir):
- Düşük harcama + Standart malzeme: Birim yöneticisi onayı yeterli.
- Orta harcama + Standart malzeme: Birim yöneticisi + satın alma müdürü.
- Yüksek harcama + Herhangi kategori: Genel müdür onayı zorunlu.
- Herhangi tutar + CAPEX: Finans direktörü + genel müdür.
Eşik Limitleri (Threshold) Belirleme

Eşiği nereye koyduğunuz, risk ile hız arasındaki tercihinizi belli eder
Eşik limitleri, onay akışını tetikleyen tutar sınırlarıdır. Doğru konumlanmış bir eşik, hem gereksiz bürokrasiyi keser hem de finansal riski kontrol altında tutar. Yanlış konumlandığında ise ya her şeyi onaya boğar ya da kritik harcamaları kaçırır.
Eşik Belirleme Kriterleri
- Şirket büyüklüğü ve cirosu: Büyük ölçekli firmalar daha yüksek eşiklerle çalışabilir.
- Sektör risk profili: Marjın yüksek olduğu sektörlerde eşikler biraz daha rahat tutulabilir.
- İşlem hacmi: Günde yüzlerce talebin işlendiği bir ortamda düşük eşik, kaçınılmaz olarak darboğaz yaratır.
- Denetim gereksinimleri: Regüle sektörlerde daha sıkı eşikler zorunlu olabilir.
Dinamik Eşik Yaklaşımı
Modern sistemler sabit eşik yerine dinamik eşik kurgulayabilir. Yani eşik koşullara göre kendiliğinden hareket eder:
- Bütçe kullanım oranına göre: Bütçenin %80’i tükendiğinde eşik otomatik düşer.
- Tedarikçi performansına göre: Düşük performanslı tedarikçilerden yapılan alımlarda eşik iner.
- Dönem sonuna göre: Çeyrek ya da yıl sonunda eşikler sıkılaştırılabilir.
Split Order (Bölünmüş Sipariş) Riski
Kullanıcının eşiği aşmamak için tek bir alımı birkaç siparişe bölmesi (order splitting) ciddi bir kontrol zafiyetidir. Uygulamada en çok karşılaşılan kaçamaklardan biridir. Bunu önlemek için:
- Aynı tedarikçi + aynı kategori + yakın tarihli siparişler otomatik olarak tespit edilmeli.
- Belirli bir periyotta aynı kullanıcının aynı kategorideki toplam harcaması izlenmeli.
- Şüpheli bir bölünme yakalandığında uyarı ya da bloke mekanizması devreye girmeli.
Yetki Devri (Delegation) Kuralları
Onay yetkilisi izne ayrıldığında, seyahatte olduğunda ya da hastalandığında akışın kilitlenmemesi için yetki devri şart. Tek bir kişinin yokluğunda tüm süreç durabiliyorsa, orada bir tasarım eksiği var demektir.
Yetki Devri Parametreleri
- Devir süresi: Başlangıç ve bitiş tarihi net tanımlanmalı.
- Devir kapsamı: Tüm yetkiler mi devrediliyor, belirli kategoriler mi, yoksa yalnızca belirli tutarın altı mı?
- Vekil kişi: Yetkinin devredildiği kişinin bu işi yürütecek yetkinliği doğrulanmalı.
- Geçmişe dönük iptal: Devir süresi içinde onaylanmış işlemler geçerliliğini korur.
Yetki Devri İş Kuralları
- Bir yetkili aynı anda yalnızca tek bir kişiye yetki devredebilir.
- Zincirleme devir (A’dan B’ye, B’den C’ye) engellenmeli ya da en azından sınırlandırılmalı.
- Devir işlemi hem devreden hem de devralan tarafından onaylanmalı.
- Tüm devir işlemleri denetim loguna kaydedilmeli.
- Aktif devir sırasında orijinal yetkili de onay verebilir (paralel yetki).
Otomatik Vekalet Ataması
Gelişmiş sistemlerde yetkili belirli bir süre onay vermezse, sistem devreye girip otomatik vekil atayabilir. Özellikle tatil dönemlerinde akışın topluca durmasını önleyen pratik bir çözüm.
Mobil Onay Entegrasyonu

Yönetici masada olmasa da onay akışı yürümeye devam edebilir
Yöneticinin masabaşında olmadığı saatlerde bile onay verebilmesi, akış hızını doğrudan etkiler. İyi bir mobil onay çözümü şu özellikleri barındırmalı:
Temel Mobil Özellikler
- Anlık bildirim (push notification): Yeni onay talebi geldiği an yetkiliye ulaşır.
- Özet görüntüleme: Tutar, tedarikçi, açıklama gibi talep detayları tek ekranda görünür.
- Tek dokunuşla işlem: Onayla / Reddet / Geri Gönder seçenekleri.
- Toplu onay: Birden fazla talep tek seferde onaylanabilir.
- Yorum ekleme: Red ya da koşullu onay için açıklama girilebilir.
Güvenlik Gereksinimleri
- Biyometrik ya da PIN doğrulama.
- Cihaz kaydı ve MDM (Mobile Device Management) entegrasyonu.
- SSL/TLS ile şifrelenmiş iletişim.
- Oturum zaman aşımı.
- Uzaktan cihaz silme (remote wipe) yeteneği.
Offline Çalışma Senaryosu
İnternet bağlantısının zayıf düştüğü ortamlar için (fabrika içi, saha ziyareti gibi) offline onay desteğini de düşünmek gerekir. Onay kararları cihazda yerel olarak tutulur, bağlantı geldiğinde senkronize edilir.
3-Way Matching: Sipariş-Teslim-Fatura Eşleşmesi

Ödemeden önceki son kontrol noktası çoğu zaman burasıdır
3-way matching, satın alma sürecinin ödeme aşamasındaki en kritik kontrollerden biridir. Burada üç belge yan yana konur:
Eşleştirilen Belgeler
- Satın Alma Siparişi (PO): Ne sipariş edildi, hangi fiyattan?
- Mal/Hizmet Teslim Belgesi (GRN): Ne teslim alındı, ne kadar?
- Tedarikçi Faturası: Ne kadar ödeme talep ediliyor?
Eşleştirme Kontrolleri
- Miktar kontrolü: Teslim alınan miktar, sipariş miktarını aşmamalı.
- Birim fiyat kontrolü: Fatura fiyatı, sipariş fiyatının üzerine çıkmamalı.
- Toplam tutar kontrolü: Fatura tutarı (miktar x fiyat + vergi) hesapla tutmalı.
Tolerans Limitleri
Küçük sapmalara takılıp kalmamak için tolerans limitleri tanımlanır:
- Miktar toleransı: Örneğin +/- %3 sapma kabul edilebilir.
- Fiyat toleransı: Örneğin +/- %2 ya da sabit bir tutar.
- Tutar toleransı: Örneğin toplam farkın belirli bir sınırın altında kalması.
Toleransın dışına taşan farklar otomatik bloke edilir ve elle inceleme gerektirir.
2-Way ve 4-Way Matching
Bazı durumlarda eşleştirmenin seviyesi değişir:
- 2-way matching: Yalnızca PO ile fatura karşılaştırılır; hizmet alımlarında sık kullanılır.
- 4-way matching: Buna bir de kalite kontrol onayı eklenir; kritik malzemeler için tercih edilir.
PO Workflow Otomasyonu
Elle yürütülen onay süreçleri hem yavaştır hem de hataya davetiye çıkarır. PO workflow otomasyonu akışı hızlandırır ve bir talebin diğerinden farklı işlenmesinin önüne geçer.
Otomasyon Adımları
Adım 1: Talep Oluşturma Otomasyonu
- Stok yeniden sipariş noktası (reorder point) tetiklemesi.
- Üretim planından doğan otomatik talep oluşturma (MRP).
- Periyodik hizmet alımları için zamanlanmış talep.
Adım 2: Onay Yönlendirme Otomasyonu
- İş kurallarına göre doğru onaycıyı otomatik belirleme.
- Koşullara göre akışı paralel ya da seri onaya çevirme.
- Eskalasyon kurallarını otomatik uygulama.
Adım 3: Sipariş Dönüştürme Otomasyonu
- Onaylanan talepten PO’yu otomatik oluşturma.
- Tedarikçiye e-posta ya da EDI ile otomatik gönderim.
- Çerçeve sözleşme kapsamındaki siparişleri otomatik eşleştirme.
Adım 4: İzleme ve Bildirim Otomasyonu
- Teslimat tarihi yaklaşan siparişler için hatırlatma.
- Geciken teslimatlar için otomatik uyarı.
- Bütçe aşım riski taşıyan talepler için erken uyarı.
RPA ve Yapay Zeka Entegrasyonu
Otomasyonu bir adım öteye taşımak için RPA (Robotic Process Automation) ve yapay zeka devreye girer:
- Fatura verilerini OCR ile otomatik okuma.
- Anomali tespiti (olağan dışı fiyat, miktar ya da tedarikçi).
- Tedarikçi performans tahmini ve risk skorlaması.
- Onay süresi tahmini ve darboğaz analizi.
Onay Akışlarında En Sık Yapılan 7 Hata
1. Aşırı Onay Katmanı Tanımlamak
Her talep için beş-altı onay adımı koymak akışı boğar. Sahada gördüğümüz kadarıyla, üç katmanı geçen süreçler hem yavaşlar hem de onaylayanları “bir öncekiler onaylamış, ben de onaylarım” tavrına iter. Böyle bir onay zaten onay değildir.
2. Eskalasyon Tanımlamamak
Onaycı izne çıktığında ya da işi yoğun olduğunda talepler günlerce bekler. Eskalasyon kuralı olmayan bir akış, tek bir kişinin yokluğunda tüm süreci kilitleyebilir.
3. Split Order Kontrolü Yapmamak
Kullanıcıların eşiği aşmamak için alımı bölmesi fark edilmez. Bu, onay mekanizmasının tümüyle devre dışı kalması demektir ve denetimde mutlaka bulgu olarak karşınıza çıkar.
4. Kategori Ayrımını Göz Ardı Etmek
Bütün satın almalara tek bir akışı dayatmak. Direkt üretim malzemesiyle ofis malzemesi aynı onaydan geçmemeli; risk profilleri baştan farklı.
5. Mobil Erişimi İhmal Etmek
Yöneticinin yalnızca masabaşından onay verebilmesi. Seyahatte ya da sahadaki yetkili günlerce onay veremez, operasyon o arada tıkanır.
6. Denetim Loglarını Tutmamak
Kim, ne zaman, neyi onayladı bilgisinin kayda geçmemesi. İç ve dış denetimde izlenebilirliğin olmaması ağır bir bulgu olarak raporlanır.
7. 3-Way Matching Atlayarak Ödeme Yapmak
Fatura gelir gelmez, sipariş ve teslim kontrolü yapmadan ödemek. Bu alışkanlık fazla ödemeye, hayali faturaya ve tedarikçi hatalarının gözden kaçmasına kapı aralar.
Hataların çoğu sistematik bir yaklaşımla baştan önlenir
Satın Alma Onay Akışı Kontrol Listesi
Aşağıdaki liste, onay akışını tasarlarken ve devreye alırken kritik adımların gözden kaçmadığını doğrulamak için:
A. Onay Matrisi Tasarımı
- Tutar aralıkları (threshold) tanımlandı
- Satın alma kategorileri belirlendi (direkt/endirekt/CAPEX/hizmet)
- Her kategori için onay hiyerarşisi oluşturuldu
- Maliyet merkezi bazlı farklılıklar tanımlandı
- Onay matrisi üst yönetim tarafından onaylandı
B. Yetki ve Erişim Kontrolleri
- Görev ayrılığı (SoD) kuralları tanımlandı
- Yetki devri mekanizması aktif
- Vekalet kuralları belirlendi (süre, kapsam, sınırlar)
- Zincirleme devir engellendi ya da sınırlandırıldı
C. Sistem Konfigürasyonu
- Onay akışı sistemde tanımlandı ve test edildi
- Eskalasyon kuralları konfigüre edildi
- Split order tespit mekanizması aktif
- E-posta ve push bildirimleri çalışıyor
- Mobil onay uygulaması devreye alındı
D. 3-Way Matching Ayarları
- Miktar, fiyat ve tutar toleransları belirlendi
- Uyumsuzluk durumunda bloke ve bildirim mekanizması aktif
- Manüel eşleştirme için yetki tanımlandı
E. İzleme ve Denetim
- Tüm onay işlemleri log kaydına alınıyor
- Onay süresi raporları tanımlandı
- Darboğaz analizi için dashboard oluşturuldu
- Periyodik denetim prosedürü belirlendi
Projenize özel bir onay akışı tasarımı için iletişim sayfasından ulaşabilirsiniz.
Sıkça Sorulan Sorular (SSS)
Projeniz İçin Destek Alın
Dijital dönüşüm yolculuğunuzda size rehberlik edebilirim. Ücretsiz ön görüşme için randevu alın.