İade raporlarınız Apple, Google ve sunucunuz arasında asla tutmaz, işte nasıl uzlaştıracağınız

İade sayısını App Store Connect'ten çekin, sonra sunucunuzdan çekin ve iki sayı tutmayacak. Üçüncüsünü finansal raporunuzdan çekin ve o da ikisinden birine uymayacak. Bu, kimsenin sisteminde bir hata değil. Apple ve Google iadeleri birden fazla yüzey üzerinden raporlar, her yüzey iadenin ömründeki farklı bir anı sayar ve sunucunuz dördüncüyü görür. Toplamlar birbirinden uzaklaştığı için iade raporlarını uzlaştırmayı hiç denediyseniz ve vazgeçtiyseniz, işte neden uzaklaştıkları, hangi işte hangi sayıya güveneceğiniz ve bunları aya göre değil işleme göre nasıl hizalayacağınız.

Bir iade neden üç farklı sayı olarak görünür

Tek bir iade, nihai hale gelmeden önce birkaç sistemden geçer ve her sistem onu farklı bir anda kaydeder. Sunucunuz onu ilk olarak bir olay olarak duyar. Hızlı bir analiz raporu onu bir sonraki adımda tahmin eder. Muhasebe raporu onu en son, para gerçekten hareket ettikten sonra kaydeder. Aynı iade, üç zaman damgası, üç toplam. Hata, bunların herhangi ikisini aynı gün eşit olması gerekiyormuş gibi ele almaktır.

Apple size iki rapor ailesi verir, artı web kancanız

Apple iadeleri, aynı araç olmayan ve belirli bir günde uyuşması amaçlanmayan iki yerde raporlar. Sales and Trends hızlı, tahmini görünümdür: günlük raporlar ertesi gün, haftalık raporlar Pazartesi günleri, aylık raporlar ay bittikten yaklaşık beş gün sonra, genellikle Pacific saatiyle sabah 8'e kadar gelir. Satışları ve gelirleri USD cinsinden, önceki ayın döviz kurlarının hareketli ortalamasını kullanarak tahmin eder, bu da onu bir eğilimi yakalamak için iyi, bir ödemeyi denkleştirmek için yanlış kılar. Payments and Financial Reports nihai görünümdür: Apple'ın mali takvimine göre ayda bir üretilir, önceki mali ay için mevcut mali ayın ilk Cuma günü hazır olur ve yalnızca o dönemde alışveriş veya iade olduysa üretilir. Ödemenize uygulanan kesinleşmiş döviz kurunu kullanır. O rapor, muhasebe kaydıdır. İkisinin yanında, sunucunuz Apple bir iadeyi verdiği anda, tek bir transaction id ile eşlenmiş App Store Server Notification REFUND bildirimini alır.

Google aynı şekilde böler

Google Play aynı bölünmeyi yansıtır. Earnings report muhasebe kaydıdır, aylık üretilir ve genellikle takip eden ayın 5'ine kadar hazır olur ve iadeleri kendi işlem türleri olarak listeler: alıcıya iade edilen para için Charge refund ve Google'ın geri verdiği hizmet ücreti için Google fee refund, her biri Full veya Partial olarak etiketlenir. Estimated sales report, alıcıların vergiler ve ücretler öncesinde ödediğini gösteren düşük gecikmeli analiz görünümüdür ve Google açıkça analiz için uygun ve muhasebe için önerilmediğini söyler. Sunucu tarafında gerçek zamanlı Real-time Developer Notification alırsınız ve bir iadeyi Voided Purchases API üzerinden geri okuyabilirsiniz.

Apple bir iadeyi rapor içinde nasıl gösterir ve negatif satır tuzağı

Summary Sales Report raporunu açın ve bir iade kendini sessizce bir satıştan çıkarmaz. Kendi satırı olarak görünür. O satırdaki Units ve Customer Price negatiftir, bir iadeyi zaten böyle fark edersiniz ve Developer Proceeds rakamı fiyatın davrandığı gibi davranmaz. Rapor doğası gereği iadeleri düşülmüş vermez. İade satırlarını satış satırlarının yanında listeler ve onları kovalara ayırmak sizin işinizdir. Units sütununu gözle toplarsanız, ya iki kez sayarsınız ya da iadeleri tamamen kaçırırsınız, çünkü eksi bir iade satırı, pozitif satışlarınızla aynı sütunda durur.

Pratik kural basittir: iadeleri negatif Units ile bulun, o satırları kendi başlarına toplayın ve raporun bunları sizin için zaten düştüğünü asla varsaymayın. İadelerinizin öne çıkan bir sonuç sayımı, bir sütunun aritmetik toplamı değil, negatif Units satırlarının sayısıdır.

Aylık toplamlarınızın asla tutmama nedeni mali takvimdir

İşte dikkatli bir hesap tablosunun bile dengelenmeyi reddetmesinin en büyük tek nedeni. Apple'ın finansal raporları takvim aylarına göre işlemez. 4-4-5 mali takvimine göre işler, burada çoğu mali ay dört haftadır ve her üçüncüsü beş haftadır. Bir Financial Report raporunu düz bir Ocak'tan Ocak'a pencereyle karşılaştıran bir geliştirici, iki farklı gün aralığını karşılaştırıyor, bu yüzden her temel sayı doğru olsa bile iade toplamları tutamaz. Apple'ın kendi forumlarındaki geliştiriciler, Sales rakamları ile Financial Report rakamlarının tam da bu nedenle binlerce dolar ayrıştığını izlediler, boşluk biriktikçe her ay genişledi.

Google'ın earnings report raporu aylıktır, ama kendi zamanlamasını ve kendi zaman dilimini taşır ve ikisi de sunucunuzun UTC saati değildir. Daha derin tuzak her iki mağazada da ortaktır: bir iade, orijinal satışın tarihine değil, nihai hale geldiği tarihe atanır. Bir Mart alışverişini Nisan başında iade edin ve Mart rakamlarınızı değil Nisan rakamlarınızı azaltır. İki ayı etiketlerine göre dizin ve iade birinden kaybolmuş, diğerinde ortaya çıkmış gibi görünür.

Bir iadenin maliyeti ve hangi raporda okunacağı

Uzlaştırma aslında bir muhasebe sorusudur, o yüzden parayı takip edin. Bir iadede mağaza kendi komisyonunu geri verir, yani hesabınızdan gerçekten çıkan tutar, müşterinin geri verildiğini gördüğü tam fiyat değil, satıştaki payınızdır. Google Play'de o geri veriş görünür bir satırdır: earnings report raporunuzdaki Google fee refund işlem türü, size geri gelen hizmet ücretidir ve alıcıya giden Charge refund kaleminin yanında durur. App Store'da Apple, komisyon sonrası gelirinizi düşer ve komisyonunu aynı hareketle geri verir, bu yüzden finansal rapor, Apple'ın payı düşülmüş haldeki düşümü gösterir.

Nakit akışı zamanlaması, geliştiricilerin sürprizle karşılaştığı yerdir. Google Play'de, bir siparişi Google size onun için ödeme yapmadan önce iade ederseniz, o tutarı hiç almazsınız. Ödemeden sonra iade ederseniz, Google onu gelecekteki bir ödemeden düşer. Ve bir iade dalgası bakiyenizi negatife iterse ve en az 48 saat negatif kalırsa, Google açığı için normalde ödemelerinizi alan banka hesabından borç kaydeder. Bir ters ibraz aynı olayın daha keskin versiyonudur: Google Play'de, 3 Ağustos 2026 tarihinde veya sonrasında verilen siparişler için ters ibraz, alış fiyatı artı bankanın ücretlerini geliştiriciye taşır ve satıştan daha sonraki bir ayın raporuna düşer.

İade raporlarınızı adım adım nasıl uzlaştıracağınız

İş, her sayıyı eşit kılmaya çalışmayı bırakıp bunun yerine her sayıyı yanıtladığı soruya atadığınızda basitleşir. Yalnızca iki soru vardır: ne kadar para hareket etti ve kimin hâlâ erişimi var.

• Bir raporu açmadan önce soruya karar verin. Para için yanıt, Apple'ın finansal raporunda ve Google'ın earnings report raporunda yaşar, nokta. Erişim için yanıt, sunucu bildirimlerinizde yaşar. Asla birini diğerine göre uzlaştırmayın.
• Dört yüzeyin tümünde birleştirme anahtarınız olarak transaction id'yi seçin. Bir satışın, iadesinin, raporların ve web kancanızın tümünün paylaştığı tek alandır.
• Apple için, Summary Sales Report ile web kancanız uyuşmadığında, App Store Server API Get Refund History uç noktasını /inApps/v2/refund/lookup/{transactionId} adresinden çağırın. Bir müşteri için imzalı iade edilmiş işlemleri revocationDate ve revocationReason ile, tek seferde bir transaction id ile döndürür ve geçmişlerini sayfalayarak dolaşır. O uç nokta belirleyicidir.
• Google için, earnings report raporundaki Charge refund satırlarını, aynı siparişler için Voided Purchases API'nin bildirdikleriyle çapraz kontrol edin ve kısmi bir iadenin Partial olarak etiketlendiğini ve orijinal ödemeyi sıfırlamayacağını unutmayın.
• Kendi saatinize değil, raporun saatine hizalanın. Apple'ınki Pacific saatiyle bir mali aydır. Google'ın earnings report raporunun kendi ayı ve zaman dilimi vardır. Günlükleriniz neredeyse kesinlikle UTC'dir. Karşılaştırmadan önce raporun takvimine çevirin, yoksa gün sınırları tek başına hayalet uyuşmazlıklar yaratır.
• Tahminin hareket etmesini bekleyin. Sales and Trends bir tahmindir ve işlemler denkleştikçe kaymaya devam eder. Finansal rapora göre uzlaştırın, asla tahmine göre ve asla tahminin dünkü anlık görüntüsüne göre değil.

Sunucunuz rapordan daha fazla iade gösterdiğinde

En yaygın panik, aynı dönem için satış raporundaki iade satırlarından daha fazla REFUND bildirimini sunucunuzda bulmaktır. Genellikle kayıp para değildir. İki yüzey farklı anları sayar, bir bildirim rapor satırını günlerce önceleyebilir ve kısmi bir iade veya yeniden gönderilen bir talep birden fazla olay üretebilir. Geliştiriciler tam olarak bu şekli bildirdi, aynı ay için daha küçük bir negatif Units satır sayısına karşı binlerce REFUND bildirimi. Bunu her seferinde aynı şekilde çözün: sunucunuzun gördüğü transaction id'leri alın, onları Get Refund History üzerinden çalıştırın ve hangilerinin gerçekten ne kadar iade edildiğini Apple'ın kendi kaydının belirlemesine izin verin.

Kısa versiyon

Apple'ın tahminini, Apple'ın finansal raporunu, Google'ın earnings report raporunu ve web kancanızı aynı gün aynı iade toplamını gösterecek hale getiremezsiniz ve denemeyi bırakmalısınız. Her birini, size anlatmak için tasarlandığı şey için okuyun. Para için finansal rapora ve earnings report raporuna güvenin, erişim için sunucu bildirimlerinize güvenin ve iki yüzey çeliştiğinde, onları transaction id üzerinde birleştirin ve Get Refund History veya Voided Purchases aramasının anlaşmazlığı çözmesine izin verin. Uzlaştırılmış iadeler eşleşen toplamlar değildir. Eşleşen işlemlerdir.