Twoje raporty zwrotów nigdy nie zgadzają się między Apple, Google i serwerem, oto jak je uzgodnić

Pobierz liczbę zwrotów z App Store Connect, potem pobierz ją z serwera, a te dwie liczby się nie zgodzą. Pobierz trzecią z Financial Report i nie zgodzi się z żadną z nich. To nie jest błąd w niczyim systemie. Apple i Google raportują zwroty przez więcej niż jedną powierzchnię, każda powierzchnia liczy inny moment w życiu zwrotu, a serwer widzi czwarty. Jeśli kiedykolwiek próbowałeś uzgodnić raporty zwrotów i poddałeś się, bo sumy się rozjeżdżają, oto dlaczego się rozjeżdżają, której liczbie ufać do którego zadania i jak zestawić je po transakcji zamiast po miesiącu.

Dlaczego jeden zwrot pojawia się jako trzy różne liczby

Pojedynczy zwrot przechodzi przez kilka systemów, zanim zostanie rozliczony, a każdy system zapisuje go w innej chwili. Twój serwer słyszy o nim najpierw, jako zdarzenie. Szybki raport analityczny szacuje go następnie. Raport księgowy rejestruje go na końcu, gdy pieniądze faktycznie się przemieściły. Ten sam zwrot, trzy znaczniki czasu, trzy sumy. Błędem jest traktowanie dwóch z nich tak, jakby miały być równe tego samego dnia.

Apple daje Ci dwie rodziny raportów, plus Twój webhook

Apple raportuje zwroty w dwóch miejscach, które nie są tym samym narzędziem i nie mają się zgadzać danego dnia. Sales and Trends to szybki, szacunkowy widok: raporty dzienne pojawiają się następnego dnia, tygodniowe w poniedziałki, miesięczne około pięciu dni po zakończeniu miesiąca, zwykle do 8 a.m. Pacific. Szacuje sprzedaż i przychody w USD, używając kroczącej średniej kursów wymiany z poprzedniego miesiąca, co czyni go dobrym do wychwytywania trendu i błędnym do uzgadniania wypłaty. Payments and Financial Reports to widok rozliczony: generowany raz w miesiącu według kalendarza fiskalnego Apple, dostępny do pierwszego piątku bieżącego miesiąca fiskalnego za poprzedni miesiąc fiskalny, i generowany tylko jeśli w tym okresie były zakupy lub zwroty. Używa ostatecznego kursu wymiany zastosowanego do Twojej wypłaty. Ten raport jest zapisem księgowym. Obok obu Twój serwer otrzymuje App Store Server Notification REFUND w chwili, gdy Apple przyznaje zwrot, powiązane z jednym transaction id.

Google dzieli tak samo

Google Play odzwierciedla podział. earnings report jest zapisem księgowym, generowanym miesięcznie i zwykle dostępnym do 5. dnia następnego miesiąca, i wymienia zwroty jako osobne typy transakcji: Charge refund za pieniądze zwrócone kupującemu i Google fee refund za opłatę serwisową, którą Google oddaje, każdy oznaczony jako Full lub Partial. estimated sales report to widok analityczny o niskim opóźnieniu, pokazujący, ile kupujący zapłacili przed podatkami i opłatami, a Google mówi wprost, że nadaje się do analityki i nie jest zalecany do księgowości. Po stronie serwera otrzymujesz Real-time Developer Notification w czasie rzeczywistym i możesz odczytać zwrot z Voided Purchases API.

Jak Apple pokazuje zwrot wewnątrz raportu i pułapka ujemnego wiersza

Otwórz Summary Sales Report, a zwrot nie odejmuje się po cichu od sprzedaży. Pojawia się jako osobny wiersz. Units i Customer Price w tym wierszu są ujemne, po czym w ogóle rozpoznajesz zwrot, a wartość Developer Proceeds nie zachowuje się tak jak cena. Raport nie jest z natury pomniejszony o zwroty. Wymienia wiersze zwrotów obok wierszy sprzedaży, a Twoim zadaniem jest je posegregować. Zsumuj kolumnę Units na oko, a albo policzysz podwójnie, albo w ogóle przeoczysz zwroty, bo wiersz zwrotu minus jeden stoi w tej samej kolumnie co Twoja dodatnia sprzedaż.

Praktyczna zasada jest prosta: znajdź zwroty po ujemnych Units, dodaj te wiersze osobno i nigdy nie zakładaj, że raport już je za Ciebie zbilansował. Liczba Twoich zwrotów nadająca się na featured snippet to liczba wierszy z ujemnymi Units, a nie arytmetyczna suma kolumny.

Kalendarz fiskalny to powód, dla którego Twoje sumy miesięczne nigdy się nie zgadzają

Oto najważniejszy pojedynczy powód, dla którego staranny arkusz nadal odmawia się zbilansowania. Raporty finansowe Apple nie działają na miesiącach kalendarzowych. Działają na kalendarzu fiskalnym 4-4-5, gdzie większość miesięcy fiskalnych ma cztery tygodnie, a co trzeci pięć tygodni. Deweloper porównujący Financial Report ze zwykłym oknem od stycznia do stycznia porównuje dwa różne zakresy dni, więc sumy zwrotów nie mogą się zgadzać, nawet jeśli każda liczba u podstaw jest poprawna. Deweloperzy na własnych forach Apple obserwowali, jak liczby Sales i liczby Financial Report rozchodziły się o tysiące dolarów właśnie z tego powodu, a luka rosła z każdym miesiącem, w którym pozwalali jej narastać.

earnings report Google jest miesięczny, ale niesie własne rozłożenie w czasie i własną strefę czasową, a żadne z nich nie jest zegarem UTC Twojego serwera. Głębsza pułapka jest wspólna dla obu sklepów: zwrot jest przypisywany do daty rozliczenia, a nie do daty pierwotnej sprzedaży. Zwróć zakup z marca na początku kwietnia, a obniży on Twoje liczby za kwiecień, a nie za marzec. Zestaw dwa miesiące po ich etykietach, a zwrot wyda się zniknąć z jednego i pojawić w drugim.

Ile kosztuje zwrot i w którym raporcie go czytać

Uzgadnianie to w istocie pytanie księgowe, więc podążaj za pieniędzmi. Przy zwrocie sklep oddaje własną prowizję, co oznacza, że kwota, która faktycznie opuszcza Twoje konto, to Twój udział w sprzedaży, a nie pełna cena, którą klient widzi zwróconą. Na Google Play ten zwrot jest widocznym wierszem: typ transakcji Google fee refund w Twoim earnings report to opłata serwisowa wracająca do Ciebie, stojąca obok Charge refund, który poszedł do kupującego. W App Store Apple odejmuje Twoje przychody po prowizji i oddaje swoją prowizję w tym samym ruchu, więc Financial Report pokazuje odliczenie pomniejszone o udział Apple.

Rozłożenie przepływu gotówki w czasie to miejsce, gdzie deweloperzy są zaskakiwani. Na Google Play, jeśli zwrócisz zamówienie, zanim Google Ci za nie zapłaci, po prostu nigdy nie otrzymasz tej kwoty. Jeśli zwrócisz po wypłacie, Google odejmie ją od przyszłej wypłaty. A jeśli fala zwrotów zepchnie Twoje saldo na minus i pozostanie ujemne przez co najmniej 48 godzin, Google obciąży kontem bankowym, które normalnie otrzymuje Twoje wypłaty, kwotą niedoboru. Chargeback to ostrzejsza wersja tego samego zdarzenia: na Google Play, dla zamówień złożonych 3 sierpnia 2026 lub później, chargeback przenosi cenę zakupu plus opłaty banku na dewelopera i ląduje w raporcie za późniejszy miesiąc niż sprzedaż.

Jak uzgodnić raporty zwrotów, krok po kroku

Zadanie staje się proste, gdy przestaniesz próbować zrównać każdą liczbę i zamiast tego przypiszesz każdą liczbę do pytania, na które odpowiada. Są tylko dwa pytania: ile pieniędzy się przemieściło i kto nadal ma dostęp.

• Zdecyduj o pytaniu, zanim otworzysz raport. Dla pieniędzy odpowiedź leży w Financial Report Apple i earnings report Google, kropka. Dla dostępu odpowiedź leży w powiadomieniach serwera. Nigdy nie uzgadniaj jednego z drugim.
• Wybierz transaction id jako klucz łączenia na wszystkich czterech powierzchniach. To jedyne pole, które dzielą sprzedaż, jej zwrot, raporty i Twój webhook.
• W Apple, gdy Summary Sales Report i Twój webhook się nie zgadzają, wywołaj endpoint Get Refund History w App Store Server API pod /inApps/v2/refund/lookup/{transactionId}. Zwraca podpisane zwrócone transakcje dla klienta, z revocationDate i revocationReason, po jednym transaction id naraz, i stronicuje przez ich historię. Ten endpoint jest rozstrzygający.
• W Google porównaj wiersze Charge refund w earnings report z tym, co Voided Purchases API raportuje dla tych samych zamówień, i pamiętaj, że częściowy zwrot jest oznaczony jako Partial i nie wyzeruje pierwotnego obciążenia.
• Wyrównaj do zegara raportu, nie do swojego. Zegar Apple to miesiąc fiskalny w czasie Pacific. earnings report Google ma własny miesiąc i strefę czasową. Twoje logi są niemal na pewno w UTC. Przelicz na kalendarz raportu, zanim porównasz, bo inaczej same granice dni stworzą fantomowe rozbieżności.
• Spodziewaj się, że szacunek się przesunie. Sales and Trends to szacunek i będzie się zmieniał, w miarę jak transakcje się rozliczają. Uzgadniaj z Financial Report, nigdy z szacunkiem i nigdy z wczorajszą migawką szacunku.

Gdy serwer pokazuje więcej zwrotów niż raport

Najczęstsza panika to znalezienie więcej powiadomień REFUND na serwerze niż wierszy zwrotów w raporcie sprzedaży za ten sam okres. To zwykle nie są utracone pieniądze. Te dwie powierzchnie liczą różne momenty, powiadomienie może wyprzedzać wiersz raportu o dni, a częściowy zwrot lub ponownie złożone żądanie może wygenerować więcej niż jedno zdarzenie. Deweloperzy zgłaszali dokładnie taki kształt, tysiące powiadomień REFUND wobec mniejszej liczby wierszy z ujemnymi Units za ten sam miesiąc. Rozwiązuj to za każdym razem tak samo: weź transaction id, które widział Twój serwer, przepuść je przez Get Refund History i pozwól własnemu zapisowi Apple rozstrzygnąć, które faktycznie zostały zwrócone i za ile.

Krótka wersja

Nie zmusisz szacunku Apple, Financial Report Apple, earnings report Google i swojego webhooka, by wszystkie pokazały tę samą sumę zwrotów tego samego dnia, i powinieneś przestać próbować. Czytaj każdy pod kątem tego, do czego jest zbudowany, by Ci powiedzieć. Ufaj Financial Report i earnings report w kwestii pieniędzy, ufaj powiadomieniom serwera w kwestii dostępu, a gdy dwie powierzchnie się kłócą, połącz je po transaction id i pozwól, by wyszukanie Get Refund History lub Voided Purchases przecięło spór. Uzgodnione zwroty to nie dopasowane sumy. To dopasowane transakcje.