Ваши отчёты о возвратах никогда не совпадают в Apple, Google и на вашем сервере, вот как их сверить

Возьмите число возвратов из App Store Connect, затем возьмите его со своего сервера, и две цифры не совпадут. Возьмите третью из финансового отчёта, и она не совпадёт ни с одной из них. Это не ошибка в чьей-то системе. Apple и Google каждая сообщает о возвратах через несколько систем, каждая система считает свой момент в жизни возврата, а ваш сервер видит четвёртый. Если вы когда-нибудь пытались сверить отчёты о возвратах и сдались, потому что итоги расходятся, вот почему они расходятся, какой цифре доверять для какой задачи и как выстроить их по транзакциям, а не по месяцам.

Почему один возврат появляется как три разные цифры

Один возврат проходит через несколько систем, прежде чем рассчитаться, и каждая система записывает его в свой момент. Ваш сервер узнаёт о нём первым, как о событии. Быстрый аналитический отчёт оценивает его следующим. Бухгалтерский отчёт фиксирует его последним, когда деньги действительно перемещены. Тот же возврат, три отметки времени, три итога. Ошибка в том, чтобы считать любые две из них равными в один и тот же день.

Apple даёт вам два семейства отчётов плюс ваш вебхук

Apple сообщает о возвратах в двух местах, которые не являются одним инструментом и не должны сходиться в конкретный день. Sales and Trends, это быстрый оценочный взгляд: ежедневные отчёты приходят на следующий день, недельные по понедельникам, месячные примерно через пять дней после конца месяца, обычно к 8 утра по времени Pacific. Он оценивает продажи и поступления в USD по скользящему среднему курсу предыдущего месяца, что делает его хорошим для отслеживания тренда и неверным для сверки выплаты. Payments and Financial Reports, это рассчитанный взгляд: формируется раз в месяц по фискальному календарю Apple, доступен к первой пятнице текущего фискального месяца за предыдущий фискальный месяц и формируется только если в этом периоде были покупки или возвраты. Он использует финальный курс, применённый к вашей выплате. Этот отчёт, это бухгалтерская запись. Наряду с обоими ваш сервер получает App Store Server Notification REFUND в момент, когда Apple предоставляет возврат, привязанный к одному transaction id.

Google делит так же

Google Play отражает то же разделение. Earnings report, это бухгалтерская запись, формируется ежемесячно и обычно доступна к 5-му числу следующего месяца, и она указывает возвраты как отдельные типы транзакций: Charge refund для денег, возвращённых покупателю, и Google fee refund для сервисного сбора, который Google возвращает, каждый помечен как Full или Partial. Estimated sales report, это аналитический взгляд с низкой задержкой, который показывает, сколько покупатели заплатили до налогов и сборов, и Google прямо говорит, что он подходит для аналитики и не рекомендуется для бухгалтерии. На стороне сервера вы получаете Real-time Developer Notification в реальном времени и можете считать возврат обратно через Voided Purchases API.

Как Apple показывает возврат внутри отчёта и ловушка отрицательной строки

Откройте Summary Sales Report, и возврат не вычтет себя тихо из продажи. Он появляется отдельной строкой. Units и Customer Price в этой строке отрицательны, именно так вы вообще замечаете возврат, а показатель Developer Proceeds ведёт себя не так, как цена. Отчёт по своей природе не учитывает возвраты как вычет. Он перечисляет строки возвратов рядом со строками продаж, и ваша задача, разложить их по корзинам. Просуммируйте столбец Units на глаз, и вы либо посчитаете дважды, либо вовсе пропустите возвраты, потому что строка возврата в минус одну единицу стоит в том же столбце, что и ваши положительные продажи.

Практическое правило простое: находите возвраты по отрицательному Units, складывайте эти строки отдельно и никогда не предполагайте, что отчёт уже вычел их за вас. Число ваших возвратов для featured snippet, это количество строк с отрицательным Units, а не арифметическая сумма столбца.

Фискальный календарь, вот почему ваши месячные итоги никогда не сходятся

Вот главная причина, по которой тщательная таблица всё равно отказывается сходиться. Финансовые отчёты Apple не работают по календарным месяцам. Они работают по фискальному календарю 4-4-5, где большинство фискальных месяцев по четыре недели, а каждый третий по пять недель. Разработчик, сравнивающий Financial Report с обычным окном с января по январь, сравнивает два разных промежутка дней, поэтому итоги возвратов не могут совпасть, даже когда каждая исходная цифра верна. Разработчики на собственных форумах Apple наблюдали, как цифры Sales и цифры Financial Report расходятся на тысячи долларов именно по этой причине, и разрыв растёт каждый месяц, пока они позволяют ему накапливаться.

Earnings report Google ежемесячный, но у него свои сроки и свой часовой пояс, и ни то, ни другое не совпадает с UTC вашего сервера. Более глубокая ловушка общая для обоих магазинов: возврат относится к дате, когда он рассчитан, а не к дате исходной продажи. Верните мартовскую покупку в начале апреля, и она уменьшит ваши апрельские цифры, а не мартовские. Выстройте два месяца по их меткам, и возврат словно исчезнет из одного и появится в другом.

Сколько стоит возврат и в каком отчёте его читать

Сверка, по сути, бухгалтерский вопрос, поэтому идите за деньгами. При возврате магазин возвращает свою комиссию, а значит сумма, которая на самом деле уходит с вашего счёта, это ваша доля продажи, а не полная цена, которую покупатель видит возвращённой. В Google Play этот возврат, видимая строка: тип транзакции Google fee refund в вашем earnings report, это сервисный сбор, возвращающийся к вам, стоящий рядом с Charge refund, ушедшим покупателю. В App Store Apple вычитает ваши поступления после комиссии и возвращает свою комиссию тем же движением, поэтому финансовый отчёт показывает вычет за вычетом доли Apple.

Сроки движения денег, вот где разработчиков застаёт врасплох. В Google Play, если вы возвращаете заказ до того, как Google вам за него заплатил, вы просто никогда не получаете эту сумму. Если вы возвращаете после выплаты, Google вычитает её из будущей выплаты. А если волна возвратов уводит ваш баланс в минус и он остаётся отрицательным не менее 48 часов, Google спишет недостачу с банковского счёта, который обычно получает ваши выплаты. Чарджбэк, это более резкая версия того же события: в Google Play для заказов, размещённых 3 августа 2026 года или позже, чарджбэк переносит цену покупки плюс банковские сборы на разработчика, и он попадает в отчёт более позднего месяца, чем продажа.

Как сверять отчёты о возвратах, шаг за шагом

Задача становится простой, как только вы перестаёте пытаться сделать каждую цифру равной и вместо этого назначаете каждой цифре тот вопрос, на который она отвечает. Вопросов всего два: сколько денег переместилось и у кого остался доступ.

• Решите вопрос, прежде чем открывать отчёт. Для денег ответ живёт в финансовом отчёте Apple и earnings report Google, и точка. Для доступа ответ живёт в серверных уведомлениях. Никогда не сверяйте одно против другого.
• Выберите transaction id как ключ соединения по всем четырём системам. Это единственное поле, которое делят продажа, её возврат, отчёты и ваш вебхук.
• Для Apple, когда Summary Sales Report и ваш вебхук расходятся, вызовите эндпоинт Get Refund History в App Store Server API по адресу /inApps/v2/refund/lookup/{transactionId}. Он возвращает подписанные возвращённые транзакции клиента с revocationDate и revocationReason, по одному transaction id за раз, и постранично проходит их историю. Этот эндпоинт, решающий голос.
• Для Google сверьте строки Charge refund в earnings report с тем, что Voided Purchases API сообщает по тем же заказам, и помните, что частичный возврат помечен как Partial и не обнулит исходное списание.
• Ориентируйтесь на часы отчёта, а не на свои. У Apple это фискальный месяц по времени Pacific. У earnings report Google свой месяц и часовой пояс. Ваши логи почти наверняка в UTC. Приводите к календарю отчёта, прежде чем сравнивать, иначе одни только границы дней создадут фантомные расхождения.
• Ожидайте, что оценка будет двигаться. Sales and Trends, это оценка, и она будет продолжать сдвигаться по мере расчёта транзакций. Сверяйте с финансовым отчётом, никогда с оценкой и никогда со вчерашним снимком оценки.

Когда ваш сервер показывает больше возвратов, чем отчёт

Самая частая паника, это найти больше уведомлений REFUND на сервере, чем строк возвратов в отчёте о продажах за тот же период. Обычно это не потерянные деньги. Две системы считают разные моменты, уведомление может опередить строку отчёта на дни, а частичный возврат или повторно поданный запрос могут породить более одного события. Разработчики сообщали именно о такой картине, тысячи уведомлений REFUND против меньшего числа строк с отрицательным Units за тот же месяц. Решайте это всегда одинаково: возьмите transaction id, которые видел ваш сервер, прогоните их через Get Refund History и позвольте собственной записи Apple решить, какие из них действительно возвращены и на какую сумму.

Короткая версия

Вы не можете заставить оценку Apple, финансовый отчёт Apple, earnings report Google и ваш вебхук показать один и тот же итог возвратов в один и тот же день, и вам стоит перестать пытаться. Читайте каждый для того, что он призван вам сказать. Доверяйте финансовому отчёту и earnings report для денег, доверяйте серверным уведомлениям для доступа, а когда две системы спорят, соединяйте их по transaction id и позвольте поиску Get Refund History или Voided Purchases разрешить спор. Сверенные возвраты, это не совпавшие итоги. Это совпавшие транзакции.