İade ve Geri Ödeme Raporu Nasıl Oluşturulur: Kapsamlı Bir Rehber

Bir mağaza %12 iade oranı bildiriyor. Ancak bu iadelerin üçte birinde fiziksel olarak geri gelen hiçbir ürün yok.

Bu durum verilerdeki bir hata değildir. Bir geri ödemenin iade olarak kaydedilmesinden kaynaklanır ki çoğu platform tam olarak bu şekilde hesaplama yapar.

Operasyon ekibinden biri sizin verdiğiniz rakama göre depo kapasitesi planlayana kadar bu ayrım kulağa gereksiz bir detay gibi gelebilir.

Bu kılavuz, bir iade ve geri ödeme raporunda nelerin yer alması gerektiğini ve bu iki kelimenin neden farklı olayları tanımladığını ele almaktadır. Ardından, aylık karşılaştırmaları sessizce bozan tarih sorununa ve raporun bir dışa aktarma dosyasından nasıl oluşturulacağına değinmektedir.

Bir iade ve geri ödeme raporunun içermesi gerekenler

Aynı görünümde beş unsurun yer alması gerekir ve oran bunlardan yalnızca biridir.

Geri ödenen tutar, geri ödeme yapılan sipariş sayısı, dönem, böldüğünüz payda ve tam ile kısmi geri ödemeler arasındaki dağılım.

Platformunuz kaydediyorsa neden kodlarını da ekleyin. Oran size sorunun büyüklüğünü söyler, nedenler ise hangi sorunla karşı karşıya olduğunuzu gösterir.

Başlangıçta kargo ve vergiyi hariç tutun. Her ikisi de genellikle ayrı takip edilir ve bunları dahil etmek, daha sonra rakamları eşleştirmeyi imkansız hale getirir.

İade ve geri ödeme aynı şey değildir

Platform dokümantasyonları bu konuda alışılmadık derecede nettir ve tam ifadeleri okumaya değer.

WooCommerce'in analiz dokümantasyonu bu ikisini doğrudan ayırır. Dokümantasyonda "geri ödeme, müşteriye parayı geri gönderen işlemi tanımlar" ifadesi yer alır.

Bu tanımın diğer yarısı ise asıl önemli olan kısımdır. İade metriği, "geri ödemenin tam veya kısmi olmasına ve malların fiziksel olarak iade edilip edilmediğine bakılmaksızın" geri ödenen tutarı kaydeder.

Dolayısıyla, hasarlı bir ürün için yapılan müşteri memnuniyeti ödemesi, geri gönderilen bir şey olmasa bile iade olarak sayılır. Fiyat düzeltmeleri de aynı şekilde değerlendirilir.

İşte bu tek cümle, e-ticaret analizlerinden alınan bir iade rakamının, depo ekibine fiziksel bir iade tahmini olarak verilemeyeceğinin nedenidir.

Kargo ve vergi de bu kapsamın dışındadır. Geri ödenen kargo ücretleri ve geri ödenen vergiler, geri ödeme rakamına dahil edilmez. Bunun yerine kargo ve vergi rakamlarında negatif değerler olarak görünürler.

Tarih sorunu

Bu sorun, tek bir hücreyi etkilemek yerine trend çizginizi değiştirir, bu da durumu daha da kötüleştirir.

WooCommerce, geri ödemeleri "iadenin gerçekleştiği tarihte (siparişin verildiği tarihte değil) negatif bir sayı olarak" kaydeder.

Bunun aylık karşılaştırmalara ne yaptığını düşünün. Şubat ayındaki bir siparişe karşılık Mart ayında yapılan bir geri ödeme Mart ayına yansır ve Şubat ayının geliri hiçbir zaman yeniden düzenlenmez.

Artık her iki ay da zıt yönlerde biraz hatalıdır. Şubat ayı olduğundan daha iyi görünürken, Mart ayı yaratmadığı bir maliyeti üstlenir.

Bu durum için savunulabilir iki çözüm vardır ve bunlardan birini yazılı olarak seçmeniz gerekir.

Raporu geri ödeme tarihine göre hazırlayın ve raporu nakit görünümü olarak etiketleyin. Bu, bankanızla ve platformunuzla eşleşir ancak kohort analiziyle asla eşleşmeyecektir.

Veya her bir geri ödemeyi orijinal sipariş tarihine yeniden atayın. Bu, satış dönemi başına gerçek resmi gösterir ancak raporu yayınladıktan sonra geçen ayın rakamının değişeceği anlamına gelir.

İkisi de yanlış değildir. Yanlış olan, hangisini kullandığınızı belirtmeden raporu yayınlamaktır.

Paydayı seçmek

Bir iade oranının bir bölene ihtiyacı vardır ve üç farklı rakam üreten üç yaygın bölen bulunur.

Payda	Oranın anlamı	En uygun kullanım alanı
Dönem içindeki siparişler	Para iadesi alan siparişlerin oranı	Müşteri hizmetleri yükü
Gönderilen ürün adedi	Geri gelen ürünlerin oranı	Depo ve stok yenileme
Net satış tutarı	Geri dönen gelir oranı	Finans ve marj

Hedef kitleye göre seçim yapın. Finansal bir inceleme tutar bazlı versiyonu isterken, operasyonel bir inceleme ürün adedini ister.

Ardından, etrafındaki satış rakamlarına dikkat edin, çünkü onlar da tanımlanmıştır. WooCommerce, brüt satışları geri ödemeler, kuponlar, vergiler ve kargo hariç fiyat çarpı miktar olarak verir; net satışları ise brüt satışlardan iadeler ve kuponlar çıkarılmış olarak tanımlar.

Buradaki ortalama sipariş değeri (AOV), net satışların sipariş sayısına bölünmesiyle elde edilir. Dolayısıyla, başka bir yerde belirtiyor olabileceğiniz AOV değerinin içinde geri ödemeler zaten yer almaktadır.

Our guide to turning raw e-commerce orders into a sales trend report covers the revenue side of the same export.

Manuel olarak nasıl yapılır?

Seçenek 1: İki toplam ve bir bölme işlemi

Dışa aktarma dosyasını ilgili dönemdeki geri ödeme kayıtlarına göre filtreleyin, ardından geri ödenen tutarı SUMIFS ile toplayın.

Etkilenen siparişleri COUNTIFS ile sayın; tek bir sipariş birden fazla geri ödeme içerebiliyorsa, önce sipariş kimliklerini tekilleştirin.

En sonda bir kez bölme işlemi yapın. Her iki toplamı da görünür tutmak, başkalarının çalışmanızı kontrol etmesini sağlar.

Sınırlara hızla ulaşırsınız. Hangi ürünlerin veya nedenlerin buna yol açtığını göremeden, tek bir dönem için tek bir oran elde edersiniz.

Seçenek 2: Geri ödeme başına bir satır

Geri ödeme başına bir satır olacak şekilde bir tablo oluşturun. Sipariş tarihi, geri ödeme tarihi, aradaki gün sayısı, geri ödenen tutar, tam veya kısmi ve neden için sütunlar ekleyin.

Sonraki tarihten önceki tarihi çıkararak gün farkını hesaplayın. Microsoft'un DATEDIF function hakkındaki kılavuzu, bu fonksiyonun "belirli senaryolar altında yanlış sonuçlar hesaplayabileceği" konusunda uyarmaktadır.

Artık rapor dilimlenebilir hale gelir: Ürüne, kategoriye, kanala, nedene veya geri ödeme gecikmesine göre.

Gecikme sütunu, değeri en çok göz ardı edilen sütundur. Satın alma işleminden 40 gün sonra yoğunlaşan geri ödemeler dayanıklılığa, 4 gün sonra yoğunlaşanlar ise beden veya açıklama sorunlarına işaret eder.

Buradaki sınır, veri hacmi ve birleştirmelerdir. Geri ödemeleri sipariş satırlarıyla ve ürün verileriyle eşleştirmek, formüllerin pratik kalabileceği sınırı aşar.

Seçenek 3: Tanımlar sekmesi

Hangi tarihi raporladığınızı, paydayı ve kargo ile verginin dahil edilip edilmediğini kaydedin.

Ardından hariç tutulanları kaydedin. Hiç gönderilmemiş iptal edilen siparişler, test işlemleri ve ters ibrazların her biri için belirlenmiş bir işlem yöntemi gerekir.

Ters ibrazlar insanların en çok unuttuğu şeydir. Para çıkar, hiçbir iade kaydedilmez ve iki sistem sonsuza dek birbiriyle çelişir.

Buradaki kısıtlama, bir kuralı yazmanın onu uygulamaya geçirmediğidir. Gelecek ay bir başkası aynı filtreleri yeniden oluşturur.

Ortak sınır. Her üç yöntem de dışa aktarma dosyasının her iki tarihi de içerdiğini varsayar. Yalnızca geri ödeme tarihi varsa, o dosyadan kohort görünümünü kurtarmak mümkün değildir.

Manuel yöntemin yavaşladığı yerler

İlk rapor bir sabahınızı alır. Dördüncüsü ise daha uzun sürer çünkü üç şey değişmiştir.

Kısmi geri ödemeler çoğalır. Üç kısmi geri ödemesi olan tek bir sipariş üç satıra dönüşür ve satırları sayarak oluşturulan sipariş sayısı artık yanlış olur.

Ürün katalogları değişir. Yeniden adlandırılan bir SKU, bir ürünün geçmişini ikiye böler ve en çok iade edilen ürün listenizin başından kaybolur.

Ardından tanımlar sessizce değişir. Birisi daha eksiksiz göründüğü için bu ay geri ödenen kargo ücretini dahil eder ve trend bozulur.

Sadece bir toplantıda ortaya çıkan dördüncü bir maliyet daha vardır. Birisi finans departmanının neden farklı bir rakama sahip olduğunu sorduğunda, cevap yanınızda getirmediğiniz bir sekmede duran tarih kuralıdır.

Araçlar tarafının kendi derlemesi AI tools for e-commerce analytics başlığında yer almaktadır.

Powerdrill Bloom ile nasıl oluşturulur?

Adım 1: Sipariş ve geri ödeme dışa aktarma dosyalarınızı yükleyin

Sipariş dosyasını ve geri ödeme dosyasını birlikte yükleyin. Powerdrill Bloom, dosyalar yüklendiğinde sütunları analiz eder; böylece eksik geri ödeme tarihleri, yinelenen sipariş kimlikleri ve tutarsız SKU değerleri herhangi bir oran hesaplanmadan önce ortaya çıkar.

Adım 2: Raporu doğal dille tanımlayın

Kuralları oluşturmak yerine onları ifade edin. Raporladığınız tarihi, paydayı, kargo ve verginin dahil edilip edilmediğini ve nelerin hariç tutulacağını belirtin.

Ardından hataları yakalayan soruları sorun. Kaç siparişin birden fazla geri ödeme içerdiğini sorun. Hangi geri ödemelerin orijinal siparişlerinin raporlama döneminin dışına düştüğünü sorun. Son olarak ürüne ve neden koduna göre oranı isteyin.

Adım 3: Grafiği, raporu veya sunumu dışa aktarın

Oranı paydasıyla birlikte, gün bazında geri ödeme gecikmesi dağılımını veya rakamın yanında tarih kuralını içeren slaytları dışa aktarın.

Sık yapılan hatalar

İadeleri fiziksel iade olarak değerlendirmek. Platform metrikleri, malların geri gelip gelmediğine bakılmaksızın geri ödenen tutarı sayar. Hangisini kastettiğinizi belirtin.

Oranı payda olmadan raporlamak. Siparişler, ürün adetleri ve tutar üç farklı sonuç verir. Raporunuzda sizinkini belirtin.

Geri ödeme tarihi ile sipariş tarihini karıştırmak. Tek bir kural seçin, bunu etiketleyin ve ikisini asla birbiriyle karşılaştırmayın.

Geri ödenen kargo ve vergiyi sessizce dahil etmek. Her ikisi de genellikle ayrı takip edilir. Bunları dahil etmek, finansla mutabakat yapmayı imkansız hale getirir.

Siparişler yerine satırları saymak. Kısmi geri ödemeler, sipariş başına birden fazla satır oluşturur. Saymadan önce tekilleştirin.

Ters ibrazları göz ardı etmek. Para, bir geri ödeme kaydı olmadan çıkar. Nerede görüneceklerine karar verin ve bunu yazın.

Yayınlanmış bir sektör oranıyla karşılaştırmak. Diğer perakendeciler başka paydalar ve başka tarih kuralları kullanır. Öncelikle kendi trendinizle karşılaştırın.

Sonuç

Geri ödeme işlemini iade tutarından ayırın, bir tarih kuralı belirleyin, bir payda seçin ve oranı, elde edildiği taban değerin yanında raporlayın.

Oran, nihai çıktı değildir. Ürüne, nedene ve geri ödeme gecikmesine göre dağılım; bir ürün listelemesini mi, beden tablosunu mu yoksa tedarikçiyi mi düzeltmeniz gerektiğini size söyleyen şeydir.

Bu dağılımı her ay yeniden oluşturmak bir gününüzü alıyorsa, sipariş dışa aktarma dosyanızda try Powerdrill Bloom deneyin. Ayrıca CSV AI assistant ve AI report generator sayfalarına da göz atabilirsiniz.

Sıkça sorulan sorular

İade ile geri ödeme arasındaki fark nedir?

Geri ödeme, parayı geri gönderen işlemdir. Bir metrik olarak iadeler ise, fiziksel olarak herhangi bir şeyin iade edilip edilmediğine bakılmaksızın, ürün ve hizmetlerin geri ödenen tutarını kaydeder.

İade oranını nasıl hesaplarım?

Geri ödenen faaliyeti belirtilen bir taban değere bölün, ardından 100 ile çarpın. Taban değer siparişler, gönderilen ürün adedi veya net satış tutarı olabilir ve her biri farklı bir rakam verir.

Geri ödeme tarihine göre mi yoksa sipariş tarihine göre mi raporlamalıyım?

Bunu etiketlediğiniz sürece her ikisi de olur. Geri ödeme tarihi platformunuzla ve bankanızla eşleşirken, sipariş tarihi her bir satış döneminin daha gerçekçi bir resmini sunar.

Geri ödenen kargo ve vergiler hesaba katılır mı?

Genellikle geri ödeme rakamının içinde yer almaz. WooCommerce, geri ödenen kargo ve vergileri bunun yerine kargo ve vergi rakamlarında raporlar.

Benim rakamım neden finans departmanınınkinden farklı?

Çoğunlukla tarih kuralından, ardından kargo, vergi ve ters ibrazların dahil edilip edilmediğinden kaynaklanır. Rakamları karşılaştırmadan önce tanımları karşılaştırın.