Bir müşteri iki hafta önce aldığı ürünü kusurlu bulup geri getirir. Depo görevlisi malı teslim alır, bir kenara koyar, satış temsilcisine haber verir. Temsilci "tamam, iade edelim" der ve muhasebeye elle bir not iletir. Bir hafta sonra aynı müşteri "param nerede" diye arar; muhasebe elindeki faturayla malın gerçekten geri geldiğini eşleştiremez, stok kaydı hâlâ satılmış görünür, kredi notu ya hiç kesilmez ya da iki kez kesilir. Kimse kötü niyetli değildir — sadece iade, satıştan farklı olarak "birinin hatırlaması gereken bir istisna" olarak yaşar.
Oysa iade, satışın aynadaki görüntüsüdür: aynı titizlikle kayıt altına alınması gereken, kendi başlangıcı ve bitişi olan bir süreç. Bu yazı, müşteriden gelen iadenin ve tedarikçiye giden iadenin ERP'de nasıl ayrı ayrı ama tutarlı bir mantıkla yönetildiğini anlatıyor.
İade neden bir "not" değil, kendi kaydı olan bir işlem olmalı?
Çoğu KOBİ'de iade, orijinal satış işleminin bir uzantısı gibi ele alınır: irsaliye üzerine elle çizik atılır, faturaya "iade edildi" yazılır, stok defterine tek satır düşülür. Bu yaklaşımın sorunu izlenebilirliğin kaybolmasıdır — altı ay sonra "bu müşteriye bu üründen kaç kez iade yapıldı" sorusuna cevap aramak, kâğıt yığınını yeniden karıştırmak anlamına gelir.
ERP'de iade, orijinal satış siparişine veya faturaya bağlı ayrı bir kayıttır:
- Hangi sipariş/fatura için iade yapıldığı
- İade edilen kalem ve miktar (kısmi iade de olabilir)
- İade nedeni (aşağıda ayrı bir mesele)
- Talep tarihi ve teslim alınma tarihi
Bu kayıt bir kez oluşturulduğunda, süreç ilerledikçe (depo teslim alımı, kalite kontrolü, mali mahsup) hep aynı referansa bağlı kalır. Kimse "hangi iadeydi bu" diye sormaz.
İade nedeni neden sonucundan daha çok konuşulmalı?
İadeyi sadece "geri geldi, kredi notunu kes" olarak görmek, altında yatan asıl bilgiyi kaçırır: neden geri geldi?
İade nedenleri kabaca dört başlıkta toplanır:
| Neden | Sonraki adım |
|---|---|
| Ürün kusurlu / bozuk geldi | Kalite kontrolüne düşer, tedarikçi sorumluluğu araştırılır |
| Yanlış ürün gönderildi | Depo sevkiyat sürecinde hata araştırılır |
| Müşteri fikrini değiştirdi | Satılabilir stoğa geri döner (ürün bozulmadıysa) |
| Sipariş fazlası / stok düzeltmesi | Cari hesap mahsubu, ürün stoka geri girer |
Bu ayrım sadece muhasebe kaydı için değil, geri bildirim için de gereklidir. Bir üründe kusurlu iade oranı belirli bir eşiği aştığında, bu bilgi tedarikçi performans değerlendirmesine ya da üretim kalite kontrolüne doğrudan yansımalı — aksi halde aynı hata sessizce tekrar eder. Seri ve lot takibi yapılan sektörlerde iade nedeni, hangi partinin sorunlu çıktığını geriye dönük izlemenin de tek yoludur.
Nedeni kaydetmeyen bir işletme, aynı sorunu her seferinde ilk kez yaşıyormuş gibi karşılar.
Geri gelen mal doğrudan satılabilir rafa mı döner?
Bu, depo tarafında en sık atlanan adımdır. Mal geri geldiğinde üç olasılık vardır:
- Doğrudan satılabilir stoğa girer — ambalajı bozulmamış, kullanılmamış, müşteri sadece fikrini değiştirmiş.
- Karantina/inceleme lokasyonuna girer — kusur iddiası var, kalite kontrolü onay verene kadar satılabilir stoktan ayrı tutulmalı.
- Doğrudan hurdaya veya tedarikçiye iadeye yönlenir — onarımı ekonomik olmayan ya da tedarikçi garantisi kapsamındaki ürünler.
Bu üç yol birbirine karıştığında iki türlü hata olur: ya kusurlu bir ürün kontrolsüz şekilde tekrar satılır, ya da sağlam bir ürün gereksiz yere aylarca karantinada bekler. ERP'de depo, iade kaydına bağlı bir "sonraki adım" alanı görür ve malı doğrudan doğru lokasyona yönlendirir — stok miktarı, malın fiziksel olarak nerede durduğuna göre değil, hangi statüde olduğuna göre güncellenir.
Kredi notu, nakit iade ve değişim — hangisi ne zaman?
Mali tarafta üç farklı kapanış şekli vardır ve her birinin cari hesaba etkisi farklıdır:
- Cari hesaba alacak (kredi notu): Müşterinin bir sonraki alışverişinde mahsup edilir; nakit çıkışı yok, cari bakiye düşer.
- Nakit/banka iadesi: Ödeme zaten tahsil edilmişse ve müşteri parasını geri istiyorsa, gerçek bir ödeme çıkışıdır.
- Ürün değişimi: Aynı anda hem çıkış (yeni ürün sevkiyatı) hem giriş (eski ürün iadesi) işlemidir; net mali etki genelde sıfıra yakındır ama iki hareket de ayrı ayrı kayda geçmelidir.
Bu üçünün karıştırılması, ay sonu mutabakatında en sık karşılaşılan sapmalardan biridir: bir muhasebeci kredi notu keser, bir başkası aynı iade için nakit iade yapar, kimse ikisinin aynı işlem olduğunu fark etmez. İade kaydı tek bir kapanış türüne bağlandığında ve o kapanış gerçekleşmeden kayıt "açık" statüsünde kaldığında, bu tekrar riski ortadan kalkar.
İade süresi geçtiğinde işletme otomatik "hayır" mı der?
Çoğu işletmenin bir iade politikası vardır — "14 gün içinde", "orijinal ambalajında", "faturayla birlikte" gibi şartlar. Sorun, bu şartların genelde kâğıt üzerinde kalması ve her seferinde satış temsilcisinin kendi takdirine göre uygulanmasıdır. Aynı gecikmeye bir müşteride "olur" denir, başka bir müşteride "olmaz" — tutarsızlık hem müşteri ilişkisini hem iç denetimi zorlar.
ERP'de iade talebi açıldığında sistem, orijinal fatura tarihiyle bugünün arasındaki farkı otomatik hesaplar ve tanımlı süreyi aşan talepleri işaretler. Bu, talebi otomatik reddetmek anlamına gelmez — yetkili bir onay adımına düşürür. Böylece istisna, sessizce kural haline gelmeden, görünür ve kayıtlı bir karar olarak kalır.
Bayiden veya zincirden gelen toplu iade farklı mı çalışır?
Perakende zincirine veya bayi ağına satış yapan üreticilerde iade tek bir müşteri değil, bir sevkiyatın tamamı olabilir — hatalı bir parti, etiket uyumsuzluğu ya da raf ömrü sorunu nedeniyle onlarca kalemlik toplu geri dönüş. Bu senaryo tek tek işlenen bireysel iadelerden farklı bir yük taşır: aynı anda çok sayıda kalemin, aynı iade nedenine ve aynı mali kapanışa bağlanması gerekir.
ERP'de toplu iade, tek bir üst kayıt altında birden fazla kalemi gruplar; her kalem kendi miktarını ve durumunu taşırken, kapanış (cari hesaba toplu alacak gibi) tek işlemde yürütülür. EDI ile çalışan zincir müşterilerde bu süreç, zincirin kendi iade bildirimiyle de eşleştirilebilir — elle tek tek girilen kalemler yerine toplu bir mutabakat söz konusu olur.
Müşteriden gelen iade ile tedarikçiye giden iade aynı akış mı?
Hayır — ve bu ikisini aynı zannetmek yaygın bir karışıklıktır. Müşteri iadesi satış tarafının, tedarikçiye iade ise satınalma tarafının işlemidir; yönleri terstir.
Bağlantı noktası şurada kurulur: müşteriden gelen kusurlu bir ürün kalite kontrolünden geçtikten sonra, "bu kusur üretim/tedarikçi kaynaklı" diye işaretlenirse, aynı kayıt bir tedarikçi iade talebini tetikleyebilir. Böylece müşteri memnuniyetsizliğinin kök nedeni tedarikçi zincirine kadar izlenebilir hale gelir — iki ayrı işlem, ama birbirine referansla bağlı.
Bu bağlantı kurulmadığında, işletme kusurlu bir ürünü müşteriye tazminat olarak öder ama aynı kusuru tedarikçisine hiç fatura etmez; kaybı iki kez üstlenir.
Birasyo'da iade süreci nasıl kurulur?
Birasyo ERP'de iade, orijinal satış veya satınalma kaydından bağımsız bir kâğıt işi değil, o kaydın devamıdır:
- İade talebi, ilgili satış siparişi veya faturayla otomatik ilişkilendirilir; hangi kalemin, hangi miktarda iade edildiği kayıt altına alınır.
- İade nedeni zorunlu bir alan olarak seçilir ve raporlanır; belirli bir üründe/tedarikçide tekrar eden nedenler ayrı bir görünümde toplanır.
- Depo, iade edilen malı satılabilir stok, karantina veya hurda lokasyonlarından birine yönlendirir; stok miktarı yalnızca onaylanan lokasyon değiştiğinde güncellenir.
- Kapanış şekli (cari hesaba alacak, nakit iade, değişim) tek bir alanda seçilir ve ilgili muhasebe kaydı otomatik oluşur; kayıt kapanmadan ikinci bir mahsup girişine izin verilmez.
- Kalite kontrolünde tedarikçi kaynaklı bulunan iadeler, Satın Alma modülünden tedarikçiye iade talebine dönüştürülebilir; iki kayıt birbirine referansla bağlı kalır.
Bu kurgu Satış modülünde sipariş ve faturayla aynı ekran ailesinde izlenir; iade, satışın bir istisnası değil, doğal bir devamı olarak görünür.
Özet
İade, orijinal satıştan bağımsız bir istisna değil, kendi kaydı, nedeni ve kapanışı olan ayrı bir süreçtir. Nedeni kaydedilmeyen iade, tekrar eden kalite sorunlarını görünmez kılar; depoda doğru lokasyona yönlendirilmeyen mal ya erken satılır ya da gereksiz yere bekler; kapanış şekli (kredi notu, nakit, değişim) net tanımlanmazsa aynı işlem birden fazla kez mahsup edilir. Müşteri iadesi ile tedarikçiye iade ayrı yönler taşır ama kalite kontrolü üzerinden birbirine bağlanmalıdır — aksi halde işletme aynı kusurun bedelini iki kez öder. ERP'de bu adımlar tek bir akışa bağlandığında iade, "kimin sorumluluğunda kaldığı belirsiz" bir alan olmaktan çıkar.
İade sürecinizin hangi noktada koptuğunu birlikte görmek isterseniz demo talebi üzerinden bir görüşme planlayabiliriz.
İlgili yazılar:
Bu yazıyı LinkedIn'de paylaşın
Başlık, özet ve hashtagler panoya kopyalanır, LinkedIn paylaş penceresi açılır — yapıştırın (Cmd/Ctrl+V) ve gönderin.
