आपकी refund रिपोर्ट Apple, Google, और आपके सर्वर के बीच कभी मेल नहीं खातीं, उन्हें कैसे मिलाएं

App Store Connect से refund की गिनती निकालें, फिर अपने सर्वर से निकालें, और दोनों संख्याएं मेल नहीं खाएंगी। तीसरी अपनी financial report से निकालें और वह भी किसी से मेल नहीं खाएगी। यह किसी के सिस्टम में कोई बग नहीं है। Apple और Google दोनों refund की रिपोर्ट एक से अधिक सतह पर देते हैं, हर सतह refund के जीवन के एक अलग क्षण को गिनती है, और आपका सर्वर एक चौथी सतह देखता है। अगर आपने कभी refund रिपोर्ट का मिलान करने की कोशिश की और छोड़ दी क्योंकि कुल संख्याएं अलग-अलग खिसक जाती हैं, तो यहां बताया गया है कि वे क्यों खिसकती हैं, किस काम के लिए किस संख्या पर भरोसा करें, और उन्हें महीने के बजाय लेनदेन के हिसाब से कैसे मिलाएं।

एक refund तीन अलग-अलग संख्याओं के रूप में क्यों दिखता है

एक अकेला refund निपटने से पहले कई सिस्टम से गुज़रता है, और हर सिस्टम उसे एक अलग क्षण में दर्ज करता है। आपका सर्वर सबसे पहले इसके बारे में सुनता है, एक घटना के रूप में। एक तेज़ एनालिटिक्स रिपोर्ट अगला अनुमान लगाती है। अकाउंटिंग रिपोर्ट इसे सबसे अंत में दर्ज करती है, एक बार पैसा वास्तव में हिल जाने के बाद। वही refund, तीन टाइमस्टैम्प, तीन कुल। गलती इनमें से किन्हीं दो को ऐसे मानना है जैसे उन्हें एक ही दिन बराबर होना चाहिए।

Apple आपको दो रिपोर्ट परिवार देता है, साथ ही आपका webhook

Apple refund को दो जगहों पर रिपोर्ट करता है जो एक ही टूल नहीं हैं और किसी दिए गए दिन मेल खाने के लिए नहीं बनी हैं। Sales and Trends तेज़, अनुमानित दृश्य है: दैनिक रिपोर्ट अगले दिन आती हैं, साप्ताहिक रिपोर्ट सोमवार को, मासिक रिपोर्ट महीना समाप्त होने के लगभग पांच दिन बाद, आमतौर पर 8 a.m. Pacific तक। यह पिछले महीने की विनिमय दरों के रोलिंग औसत का उपयोग करके बिक्री और आय का USD में अनुमान लगाता है, जो इसे किसी रुझान को पहचानने के लिए अच्छा और किसी भुगतान को मिलाने के लिए गलत बनाता है। Payments and Financial Reports निपटा हुआ दृश्य है: Apple के वित्तीय कैलेंडर पर महीने में एक बार तैयार होता है, पिछले वित्तीय महीने के लिए मौजूदा वित्तीय महीने के पहले शुक्रवार तक उपलब्ध, और केवल तभी तैयार होता है जब उस अवधि में खरीद या refund हुए हों। यह आपके भुगतान पर लागू अंतिम विनिमय दर का उपयोग करता है। वह रिपोर्ट अकाउंटिंग रिकॉर्ड है। दोनों के साथ-साथ, आपका सर्वर App Store Server Notification REFUND उसी क्षण प्राप्त करता है जब Apple refund देता है, एक अकेले transaction id से कुंजीबद्ध।

Google उसी तरह बांटता है

Google Play इस विभाजन को प्रतिबिंबित करता है। earnings report अकाउंटिंग रिकॉर्ड है, मासिक रूप से तैयार होती है और आमतौर पर अगले महीने की 5 तारीख तक उपलब्ध होती है, और यह refund को उनके अपने लेनदेन प्रकार के रूप में सूचीबद्ध करती है: खरीदार को लौटाए गए पैसे के लिए Charge refund और Google द्वारा वापस दिए गए सेवा शुल्क के लिए Google fee refund, हर एक को Full या Partial टैग किया जाता है। estimated sales report कम-विलंब वाला एनालिटिक्स दृश्य है जो दिखाता है कि खरीदारों ने कर और शुल्क से पहले क्या भुगतान किया, और Google साफ़ कहता है कि यह एनालिटिक्स के लिए उपयुक्त है और अकाउंटिंग के लिए अनुशंसित नहीं है। सर्वर की ओर से आपको real-time Real-time Developer Notification मिलती है और आप Voided Purchases API से एक refund को वापस पढ़ सकते हैं।

Apple रिपोर्ट के अंदर एक refund कैसे दिखाता है, और ऋणात्मक-लाइन का जाल

Summary Sales Report खोलें और एक refund चुपचाप खुद को किसी बिक्री से नहीं घटाता। यह अपनी खुद की पंक्ति के रूप में दिखता है। उस पंक्ति पर Units और Customer Price ऋणात्मक होते हैं, जिससे आप refund को पहचान पाते हैं, और Developer Proceeds का आंकड़ा उस तरह व्यवहार नहीं करता जैसे कीमत करती है। रिपोर्ट स्वाभाविक रूप से refund के शुद्ध रूप में नहीं होती। यह refund की पंक्तियों को बिक्री की पंक्तियों के बगल में सूचीबद्ध करती है, और उन्हें बांटना आपका काम है। Units कॉलम को नज़र से जोड़ें और आप या तो दोगुना गिनेंगे या refund को पूरी तरह चूक जाएंगे, क्योंकि एक ऋण-एक refund पंक्ति आपकी धनात्मक बिक्री के समान कॉलम में बैठती है।

व्यावहारिक नियम सरल है: refund को ऋणात्मक Units से खोजें, उन पंक्तियों को अपने आप जोड़ें, और कभी न मानें कि रिपोर्ट ने आपके लिए उन्हें पहले ही घटा दिया है। आपके refund की featured snippet गिनती ऋणात्मक-Unit पंक्तियों की गिनती है, न कि किसी कॉलम का अंकगणितीय योग।

वित्तीय कैलेंडर ही कारण है कि आपके मासिक कुल कभी मेल नहीं खाते

यहां एकमात्र सबसे बड़ा कारण है कि एक सावधानीपूर्वक बनाई गई स्प्रेडशीट फिर भी संतुलित होने से इनकार करती है। Apple की financial रिपोर्ट कैलेंडर महीनों पर नहीं चलतीं। वे 4-4-5 वित्तीय कैलेंडर पर चलती हैं, जहां अधिकांश वित्तीय महीने चार सप्ताह के होते हैं और हर तीसरा पांच सप्ताह का। एक डेवलपर जो किसी Financial Report की तुलना सादे जनवरी-से-जनवरी विंडो से करता है, वह दिनों के दो अलग-अलग विस्तार की तुलना कर रहा है, इसलिए refund कुल मेल नहीं खा सकते भले ही हर अंतर्निहित संख्या सही हो। Apple के अपने फ़ोरम पर डेवलपर ने इसी कारण से Sales के आंकड़ों और Financial Report के आंकड़ों को हज़ारों डॉलर तक अलग होते देखा है, हर महीने जब वे इसे जमा होने देते हैं तो अंतर बढ़ता जाता है।

Google की earnings report मासिक है, लेकिन यह अपनी खुद की समय-सीमा और अपना खुद का टाइमज़ोन रखती है, और दोनों में से कोई आपके सर्वर की UTC घड़ी नहीं है। गहरा जाल दोनों स्टोर में साझा है: एक refund उस तारीख को जिम्मेदार ठहराया जाता है जब वह निपटता है, न कि मूल बिक्री की तारीख को। अप्रैल की शुरुआत में मार्च की खरीद का refund करें और यह आपके मार्च के नहीं, बल्कि आपके अप्रैल के आंकड़ों को कम करता है। दो महीनों को उनके लेबल से पंक्तिबद्ध करें और refund एक से गायब और दूसरे में प्रकट होता प्रतीत होता है।

एक refund की लागत क्या है, और उसे किस रिपोर्ट में पढ़ें

मिलान वास्तव में एक अकाउंटिंग सवाल है, इसलिए पैसे का पीछा करें। refund पर स्टोर अपना खुद का कमीशन लौटा देता है, जिसका मतलब है कि जो राशि वास्तव में आपके खाते से जाती है वह बिक्री में आपका हिस्सा है, न कि पूरी कीमत जो ग्राहक को लौटाई हुई दिखती है। Google Play पर वह वापसी एक दृश्यमान लाइन है: आपकी earnings report पर Google fee refund लेनदेन प्रकार वह सेवा शुल्क है जो आपको वापस आ रहा है, जो खरीदार को गए Charge refund के बगल में बैठा है। App Store पर, Apple आपकी कमीशन-पश्चात आय काटता है और उसी गति में अपना कमीशन वापस देता है, इसलिए financial report Apple के हिस्से के शुद्ध रूप में कटौती दिखाती है।

जहां डेवलपर चौंक जाते हैं वह नकदी-प्रवाह का समय है। Google Play पर, अगर आप किसी ऑर्डर का refund करते हैं इससे पहले कि Google ने आपको इसके लिए भुगतान किया हो, तो आप बस वह राशि कभी प्राप्त नहीं करते। अगर आप भुगतान के बाद refund करते हैं, तो Google इसे किसी भविष्य के भुगतान से काट लेता है। और अगर refund की एक लहर आपके शेष को ऋणात्मक कर देती है और यह कम से कम 48 घंटे तक ऋणात्मक रहता है, तो Google कमी के लिए उस बैंक खाते से पैसे निकालेगा जो सामान्यतः आपके भुगतान प्राप्त करता है। एक chargeback उसी घटना का तीखा संस्करण है: Google Play पर, August 3, 2026 को या उसके बाद दिए गए ऑर्डर के लिए, chargeback खरीद कीमत और बैंक के शुल्क को डेवलपर पर ले जाता है, और यह बिक्री की तुलना में बाद के महीने की रिपोर्ट पर आता है।

अपनी refund रिपोर्ट का मिलान कैसे करें, चरण-दर-चरण

यह काम तब सरल हो जाता है जब आप हर संख्या को बराबर बनाने की कोशिश करना बंद कर देते हैं और इसके बजाय हर संख्या को उस सवाल को सौंपते हैं जिसका वह जवाब देती है। केवल दो सवाल हैं: कितना पैसा हिला, और किसके पास अभी भी एक्सेस है।

• रिपोर्ट खोलने से पहले सवाल तय करें। पैसे के लिए, जवाब Apple की financial report और Google की earnings report में रहता है, बस। एक्सेस के लिए, जवाब आपकी सर्वर सूचनाओं में रहता है। कभी एक का दूसरे के मुकाबले मिलान न करें।
• सभी चार सतहों पर अपनी जॉइन कुंजी के रूप में transaction id चुनें। यह वह एकमात्र फ़ील्ड है जिसे एक बिक्री, उसका refund, रिपोर्ट, और आपका webhook सभी साझा करते हैं।
• Apple के लिए, जब Summary Sales Report और आपका webhook असहमत हों, तो App Store Server API Get Refund History endpoint को /inApps/v2/refund/lookup/{transactionId} पर कॉल करें। यह किसी ग्राहक के लिए हस्ताक्षरित refund किए गए लेनदेन लौटाता है, revocationDate और revocationReason के साथ, एक बार में एक transaction id, और उनके इतिहास के पन्ने पलटता है। वह endpoint निर्णायक है।
• Google के लिए, earnings report पर Charge refund लाइनों की क्रॉस-जांच उसी ऑर्डर के लिए Voided Purchases API जो रिपोर्ट करता है उसके मुकाबले करें, और याद रखें कि आंशिक refund को Partial टैग किया जाता है और यह मूल शुल्क को शून्य नहीं करेगा।
• रिपोर्ट की घड़ी पर संरेखित हों, अपनी नहीं। Apple की Pacific समय में एक वित्तीय महीना है। Google की earnings report का अपना महीना और टाइमज़ोन है। आपके लॉग लगभग निश्चित रूप से UTC हैं। तुलना करने से पहले रिपोर्ट के कैलेंडर में बदलें, वरना अकेले दिन की सीमाएं काल्पनिक बेमेल पैदा करेंगी।
• अनुमान के हिलने की अपेक्षा करें। Sales and Trends एक अनुमान है और जैसे-जैसे लेनदेन निपटते हैं यह खिसकता रहेगा। financial report के मुकाबले मिलान करें, कभी अनुमान के मुकाबले नहीं, और कभी अनुमान के कल के स्नैपशॉट के मुकाबले नहीं।

जब आपका सर्वर रिपोर्ट से अधिक refund दिखाए

सबसे आम घबराहट उसी विंडो के लिए sales report में refund पंक्तियों की तुलना में अपने सर्वर पर अधिक REFUND सूचनाएं पाना है। यह आमतौर पर खोया हुआ पैसा नहीं है। दोनों सतहें अलग-अलग क्षणों को गिनती हैं, एक सूचना रिपोर्ट पंक्ति से कई दिन पहले आ सकती है, और एक आंशिक refund या फिर से जमा किया गया अनुरोध एक से अधिक घटना पैदा कर सकता है। डेवलपर ने ठीक इसी आकार की रिपोर्ट की है, उसी महीने के लिए ऋणात्मक-Unit पंक्तियों की छोटी गिनती के मुकाबले हज़ारों REFUND सूचनाएं। इसे हर बार उसी तरह हल करें: अपने सर्वर ने जो transaction id देखे उन्हें लें, उन्हें Get Refund History से चलाएं, और Apple के अपने रिकॉर्ड को यह तय करने दें कि वास्तव में कौन से refund हुए और कितने के लिए।

संक्षिप्त संस्करण

आप Apple के अनुमान, Apple की financial report, Google की earnings report, और अपने webhook को एक ही दिन एक ही refund कुल दिखाने के लिए नहीं बना सकते, और आपको कोशिश करना बंद कर देना चाहिए। हर एक को उसके लिए पढ़ें जो वह बताने के लिए बना है। पैसे के लिए financial report और earnings report पर भरोसा करें, एक्सेस के लिए अपनी सर्वर सूचनाओं पर भरोसा करें, और जब दो सतहें लड़ें, तो उन्हें transaction id पर जोड़ें और Get Refund History या Voided Purchases लुकअप को निर्णय करने दें। मिलाए गए refund मिलाए गए कुल नहीं हैं। वे मिलाए गए लेनदेन हैं।