Komisyon, Hakediş ve Mutabakat Sistemi Nasıl Kurulur?

Komisyon ve Hakediş Sistemi Pazaryerinin Finansal Defteridir

Pazaryerinde müşteriden tahsil edilen tutar ile satıcıya ödenecek tutar aynı değildir. Komisyon, kampanya, kargo, iade ve diğer sözleşmesel kalemler satıcı bazında izlenebilir finansal hareketlere dönüşmelidir.

Amaç yalnız 'net tutar' göstermek değil, bu tutarın hangi sipariş kalemlerinden ve hangi kurallardan oluştuğunu sonradan açıklayabilmektir.

1. Komisyon Kuralı Modeli

• Varsayılan platform oranı.
• Kategori bazlı oran.
• Satıcı bazlı özel oran.
• Ürün/marka bazlı istisna gerekiyorsa.
• Tarih aralıklı kampanya oranı.
• Minimum/sabit ücret gerekiyorsa.

Birden fazla kural çakıştığında öncelik sırası açık olmalıdır.

2. Komisyon Matrahını Tanımlayın

Komisyonun hangi tutar üzerinden hesaplandığı sözleşme ve sistemde aynı tanıma sahip olmalıdır.

• Ürün brüt tutarı.
• İndirim sonrası tutar.
• Vergi dahil/hariç yaklaşımı iş modeline göre.
• Kargo dahil mi?
• Platform kuponu nasıl etkiler?
• Satıcı kuponu nasıl etkiler?

3. Komisyonu Kalem Seviyesinde Hesaplayın

Sipariş kalemi seviyesindeki hesaplama kısmi iade, farklı kategori oranları ve satıcı ayrımı için daha güvenlidir.

4. Finansal Snapshot

Sipariş anında kullanılan komisyon kuralının sürümünü veya sonucunu işlem kaydında saklayın.

• Kural ID/sürüm.
• Matrah.
• Oran.
• Komisyon tutarı.
• İndirim dağılımı.
• Satıcı brüt payı.
• Netleşmeyi etkileyen diğer kalemler.

Kategori komisyonu yarın değişse bile dünkü siparişin geçmiş hesabı bozulmamalıdır.

5. Kampanya Maliyetini Kim Karşılıyor?

Platform finansmanlı

İndirim müşteriye verilir; satıcı payının nasıl korunacağı kurala göre hesaplanır.

Satıcı finansmanlı

İndirim satıcının brüt gelirini etkiler.

Ortak finansmanlı

Maliyet taraflar arasında tanımlı oranla paylaşılır.

Kampanya motoru finansal hareketlere maliyet sahibi bilgisini aktarmalıdır.

6. Hakediş Nedir?

Hakediş, satıcıya belirli kurallar ve olaylar sonrasında ödenebilir hale gelen net finansal alacaktır. Sipariş alındığı anda mutlaka ödenebilir hale gelmesi gerekmez.

• Ödeme başarılı.
• Sipariş kargolandı.
• Teslim edildi.
• İade/itiraz bekleme süresi geçti.
• Risk kontrolü tamamlandı.

Hangi olayın hakedişi olgunlaştırdığı iş modeli ve sözleşmede açıkça tanımlanmalıdır.

7. Hakediş Durumları

• Bekleyen.
• Olgunlaşmayı bekliyor.
• Ödenebilir.
• Ödeme planında.
• Ödendi.
• Bloke/incelemede.
• Mahsup edildi/ters kayıt ilişkili.

8. Hakediş Takvimi

Ödeme sıklığı günlük, haftalık veya dönemsel olabilir. Satıcıya yalnız tarih değil, hangi siparişlerin hangi döneme girdiği de gösterilmelidir.

• Kesim tarihi.
• Olgunlaşma kuralı.
• Minimum ödeme eşiği varsa.
• Tatil/iş günü davranışı.
• Risk blokesi.
• Ödeme durumu.

9. Finansal Hareket Defteri

Satıcı bakiyesini tek bir değişken olarak tutmak yerine hareketlerden türetmek denetlenebilirliği artırır.

• Satış alacağı.
• Komisyon kesintisi.
• Kampanya katkısı.
• Kargo/servis kalemi.
• İade.
• Düzeltme.
• Mahsup.
• Ödeme.

Her hareket kaynak sipariş, kalem veya ödeme kaydıyla ilişkilendirilmelidir.

10. Değiştirilemez Geçmiş ve Ters Kayıt

Hatalı veya sonradan değişen finansal sonucu eski satırı silerek düzeltmeyin. Orijinal hareketi referanslayan ters/düzeltme hareketi oluşturun.

11. Ödeme Öncesi İade

İade hakediş ödenmeden gerçekleşirse ilgili alacak ve komisyon kurala göre ters çevrilerek ödeme döneminden çıkarılabilir.

12. Ödeme Sonrası İade

Satıcıya ödeme yapıldıktan sonra iade oluşursa sözleşmesel modele göre negatif bakiye, sonraki hakedişten mahsup veya başka tanımlı yöntem gerekebilir.

13. Kısmi İade

Bir siparişin yalnız bir kalemi veya kalemin bir kısmı iade edilebilir. Finansal motor ilgili tutar kadar komisyon ve satıcı alacağını ters çevirebilmelidir.

Yuvarlama kuralları özellikle oranlı indirim ve vergi hesaplarında tutarlı olmalıdır.

14. İptal Finansal Akışı

Tahsilat öncesi iptal ile tahsilat sonrası iptal aynı finansal olay değildir.

• Tahsilat yoksa finansal hareket oluşmayabilir.
• Tahsilat varsa refund gerekebilir.
• Komisyon kazanılmış sayılıyor mu?
• Kargo/servis maliyeti oluştu mu?

İptal nedeni satıcı performansını da etkileyebilir; finans ve performans kayıtları aynı olayı farklı amaçlarla kullanır.

15. Satıcı Ekstresi

• Dönem.
• Sipariş/kalem.
• Brüt satış.
• İndirim.
• Komisyon.
• Kargo/diğer.
• İade/mahsup.
• Net hareket.
• Hakediş durumu.
• Ödeme referansı.

Satıcı toplamdan işlem detayına drill-down yapabilmelidir.

16. Platform Gelir Raporu

GMV ile platform gelirini ayırın.

• Brüt/net GMV.
• Komisyon geliri.
• Sabit/servis gelirleri.
• Kampanya maliyeti.
• Refund etkisi.
• Ödeme/operasyon maliyetleri ayrı analiz edildiğinde katkı.

17. Satıcı Mutabakatı

Platform ledger'ı ile satıcıya sunulan ekstre ve gerçekleştirilen ödeme aynı toplamı açıklayabilmelidir.

1. Dönem hareketlerini kilitle/özetle.
2. Bekleyen istisnaları ayır.
3. Ödenebilir net tutarı hesapla.
4. Ekstre oluştur.
5. Ödeme talimatını oluştur.
6. Ödeme sonucunu kaydet.
7. Fark varsa istisnaya al.

18. Ödeme Sağlayıcı Mutabakatı

Müşteri tahsilatları ve refund kayıtları sağlayıcı raporuyla karşılaştırılmalıdır. Satıcı ledger'ı, müşteri tahsilatı ve sağlayıcı kaydı arasında iz sürülebilmelidir.

19. Banka/Ödeme Sonucu

• Planlandı.
• Gönderildi.
• Başarılı.
• Başarısız.
• İade döndü.
• Tekrar işlem gerekiyor.

Başarısız satıcı ödemesi 'ödendi' kabul edilmemeli; neden ve tekrar deneme süreci kaydedilmelidir.

20. Hakediş Hesabı Değişikliği

Satıcının ödeme hesabı değiştiğinde eski ve yeni bilgi, doğrulama ve değişikliği yapan kullanıcı izlenmelidir.

• Yeniden kimlik doğrulama.
• Yetkili rol kontrolü.
• Değişiklik bildirimi.
• Risk durumunda bekleme/onay.
• Audit log.

21. Yetki Ayrımı

Finansal riskin azaltılması için mümkünse kural tanımlama, ödeme hazırlama ve ödeme onaylama yetkilerini tek kullanıcıda toplamamayı değerlendirin.

Küçük ekiplerde süreç daha sade olabilir; kritik işlemlerde en azından güçlü audit ve yeniden doğrulama bulunmalıdır.

22. Finansal İstisna Kuyruğu

• Tutar uyuşmazlığı.
• Çift kayıt şüphesi.
• Negatif bakiye.
• Başarısız payout.
• Orphan payment.
• Refund uyuşmazlığı.
• Komisyon kuralı bulunamadı.
• Yuvarlama farkı.

İstisna kapatılırken neden ve çözüm kodu kaydedilmelidir.

23. Finansal Raporlarda Değişmez Kimlikler

• order_id.
• seller_order_id.
• order_item_id.
• payment_id.
• provider_transaction_id.
• ledger_entry_id.
• payout_id.
• refund_id.

Destek ve finans ekipleri aynı işlemi bu kimliklerle uçtan uca izleyebilmelidir.

24. Komisyon ve Hakediş Testleri

1. İki satıcı, iki farklı komisyon oranı.
2. Platform kuponlu sipariş.
3. Satıcı indirimli sipariş.
4. Ödeme öncesi iptal.
5. Ödeme sonrası tam refund.
6. Tek kalem kısmi refund.
7. Hakediş öncesi iade.
8. Hakediş sonrası iade/mahsup.
9. Aynı callback iki kez.
10. Başarısız satıcı payout.
11. Komisyon oranı siparişten sonra değişti.
12. Dönem mutabakat toplamı.

25. Finans KPI'ları

• Mutabakat farkı sayısı/tutarı.
• Başarısız payout.
• Hakediş hesaplama hatası.
• Refund işleme süresi.
• Finansal istisna çözüm süresi.
• Satıcı finans destek talebi.
• Manuel düzeltme oranı.

Uygulama: Komisyon ve Hakediş Kural Kitabı

1. Komisyon kural hiyerarşisini yazın.
2. Komisyon matrahını tanımlayın.
3. Kampanya maliyet sahipliğini belirleyin.
4. Hakediş olgunlaşma olayını seçin.
5. Hakediş takvimini yazın.
6. Ledger hareket tiplerini tanımlayın.
7. İade ve ters kayıt kurallarını yazın.
8. Ödeme sonrası iade/mahsup yöntemini belirleyin.
9. Satıcı ekstresi alanlarını oluşturun.
10. Mutabakat akışını yazın.
11. Finansal istisna kuyruğunu tanımlayın.
12. 12 test senaryosunu kabul planına ekleyin.

KMK Pazaryeri Platformunu İnceleyinÇok satıcılı sipariş, komisyon ve hakediş altyapısının hazır pazaryeri platformundaki karşılığını inceleyin.

Checkout, ödeme ve finansal motor artık tanımlı. Sonraki bölümde kargo, teslimat, iade ve müşteri hizmetleri operasyonunu kurarak siparişin fiziksel yaşam döngüsünü tamamlayacağız.