Если магазин приложений не выплатил доход разработчику, начните не с общей цифры продаж, а с последнего закрытого финансового отчёта и ожидаемого payout. Продажи в аналитике, начисленные proceeds и деньги, фактически отправленные в банк, относятся к разным стадиям. Проверьте действующий платный договор, налоговый статус, порог выплаты, реквизиты, валюту и календарь конкретной витрины. Затем сопоставьте строки по приложению, SKU или product ID, стране продажи, типу операции, возвратам и корректировкам. Если кабинет закрыт, приложение снято с публикации или аккаунт прекращён, письменно запросите финальные statements и расчёт остатка: исчезновение доступа не объясняет судьбу уже закрытых начислений. Когда платёж помечен отправленным, нужны дата, сумма, валюта и банковский reference; когда он не создан — причина hold и недостающее условие. Не передавайте пароль, ключ подписи приложения, коды двухфакторной защиты или доступ к банку посредникам, обещающим «разморозить» доход. Ниже — маршрут для российского ИП или компании без обещания результата: от сверки proceeds до претензии правильному юридическому лицу.
Коротко
Начните с закрытого financial statement: он показывает расчётный период и proceeds, тогда как dashboard продаж может содержать предварительные данные.
- Скачайте sales reports, financial statements, историю payouts, договор, налоговый статус и банковскую выписку до потери доступа.
- Проверьте платный договор, legal entity, порог, календарь, валюту и статус банковского или налогового профиля.
- Сведите продажи, возвраты, корректировки и выплаты по SKU, product ID, стране и расчётному периоду.
- Запросите причину hold либо банковский reference, затем предъявите рассчитанный бесспорный остаток [сумма].
Не смешивайте четыре разных вопроса: сколько покупатели заплатили, сколько магазин приложений признал proceeds, сколько стало payable и сколько поступило в банк. Пока неизвестен пропавший переход, фраза «не выплатили продажи» слишком широка для банка, поддержки и суда.
Магазин приложений показывает несколько денежных цифр
Прямой ответ: сумма в разделе аналитики редко является готовой суммой банковской выплаты.
В одной панели могут соседствовать gross sales, estimated proceeds, текущий balance и завершённые payouts. Gross отражает цену для покупателя или агрегированную стоимость операций. Proceeds — долю разработчика после предусмотренных элементов. Balance может включать ещё не закрытый период. Payout означает отдельное перечисление, которое либо только запланировано, либо уже ушло в банковскую систему. Магазин приложений не обязан использовать именно эти английские названия, поэтому сначала скачайте описание полей вашего магазина приложений.
Практический тест прост: возьмите одну покупку и проследите её от order ID до строки финансового отчёта, а затем до payout. Если этого сделать нельзя, общий виджет не годится как расчёт долга. Для подписки повторите тест на продлении и возврате. Для пакетной выплаты найдите, какие периоды и валюты она объединяет. Только после этого понятно, исчезли продажи, не закрылись proceeds или задержался банковский перевод.
Сначала находят последний нормальный расчётный цикл
Прямой ответ: сравнение с предыдущей успешной выплатой быстрее локализует отклонение, чем переписка о всём сроке существования приложения.
Сохраните предыдущий statement, письмо о payout и строку в банковской выписке. Запишите дату конца отчётного периода, дату формирования отчёта, дату отправки, валюту, сумму до банковских удержаний и назначение. Рядом разместите спорный период. Если в нём нет financial statement, проблема возникла до расчёта. Если statement есть, но payout отсутствует, проверяйте договор, threshold, tax и banking status. Если payout помечен paid, переходите к банковскому reference.
Такой контрольный месяц также выявляет незаметные изменения: другой legal entity, новый vendor ID, смену primary bank account, новую валюту или неподписанный договор. Магазин приложений мог обновить интерфейс, но состав доказательства остаётся предметным: две сопоставимые цепочки и одно точное различие.
Financial statement важнее графика установок
Прямой ответ: установки и даже подтверждённые покупки объясняют спрос, но денежное требование строится по расчётной отчётности.
Выгрузите два набора. Первый — Sales and Trends или его аналог: дата, продукт, страна, quantity, sale/return, тип подписки. Второй — Payments and Financial Reports либо отчёт монетизации: период, валюта proceeds, корректировки и сумма к расчёту. Не пытайтесь заставить файлы совпасть построчно, если один агрегирован по дате покупки, а другой — по settlement date. Сначала изучите документацию полей.
Магазин приложений может включить поздний refund в следующий финансовый период. Тогда текущий payout будет меньше, хотя исходная продажа находилась в прошлом отчёте. Сохраните обе строки и связь по product ID или иному доступному ключу. Если магазин приложений не выдаёт transaction-level mapping, запросите методику сверки и перечислите конкретные расхождения по продуктам, странам и типам операций.
В App Store ориентируются на Partner Share и fiscal month
Прямой ответ: в отчёте Apple цену покупателя и proceeds разработчика показывают разными полями, а расчётный месяц не обязан совпадать с календарным.
Официальное описание полей финансового отчёта App Store Connect называет Customer Price, Partner Share, Extended Partner Share, Partner Share Currency, Settlement Date и Sale or Return. Для расчёта берите Extended Partner Share по относимым строкам, учитывайте возвраты R и не умножайте quantity второй раз. Разделяйте валюту покупателя и валюту доли партнёра.
Apple использует fiscal calendar. Поэтому продажи последних календарных дней могут попасть в иной период, чем ожидает бухгалтер. Зафиксируйте Start Date и End Date из statement, а не подписывайте файл просто «июль». Магазин приложений также может консолидировать proceeds по валютам в одну выплату за fiscal month. Расхождение в дате само по себе ещё не задержка; задержка появляется после выполнения условий и истечения применимого календаря.
В Google Play сначала проверяют payments profile
Прямой ответ: для Google Play кабинет разработчика и merchant payments profile выполняют разные функции, поэтому доступ к одному не подтверждает готовность другого.
В Google Payments Center хранятся юридические, налоговые и банковские данные merchant account, история транзакций, payout reports и статусы платёжного метода. Установите payments profile ID и пользователей с полномочиями на платежи. Разработчик мог видеть приложение в Play Console, но не иметь роли для просмотра или исправления платёжного профиля. Это организационный пробел, а не доказательство отсутствия дохода.
Официальный календарь merchant payouts Google указывает, что выплаты разработчикам Google Play инициируются 15-го числа за продажи предыдущего месяца, при этом конкретный billing account, threshold, выходные и банковский способ могут сдвигать фактическое поступление. Не превращайте общую дату в обещание зачисления в ту же минуту: отдельно учитывайте начало payout и срок банка.
RuStore связывает срок с фактическим платежом пользователя
Прямой ответ: для российского магазина нужно читать оферту и отчёт монетизации вместе, потому что срок и состав удержаний описываются в разных документах.
В юридическом FAQ RuStore по монетизации указано, что для юридического лица или ИП доход перечисляется после удержания вознаграждения компании и за вычетом возвратов, отменённых и мошеннических платежей; там же приведён срок, исчисляемый от фактического списания у пользователя. Проверяйте действующий текст на дату каждой группы операций, а не переносите срок Apple или Google.
Помесячную сверку делайте по официальному описанию отчёта монетизации RuStore. Если одна покупка исключена как отменённая или мошенническая, запросите доступный идентификатор и денежный эффект. Не требуйте раскрывать антифрод-модель целиком. Задача разработчика — проверить собственную строку и убедиться, что одно уменьшение не применено дважды.
Порог выплаты проверяют по стране банка и валюте
Прямой ответ: threshold — это условие формирования выплаты, а не комиссия за вывод и не основание перевести деньги посреднику.
У Apple порог зависит от сочетания страны или региона банка и валюты счёта; для прочих сочетаний официальный справочник minimum payment threshold задаёт отдельное правило. У Google threshold может быть настроен в payments profile. У другого магазина приложений может действовать фиксированный минимум либо вовсе иной механизм. Сохраните страницу настройки и значение на дату ожидаемого payout.
Проверяйте carryover раздельно по тем валютам и территориям, для которых отчёт ведёт самостоятельный остаток. Небольшие суммы могут переноситься несколько циклов, а затем объединяться только на стадии банковского платежа. В рабочем листе оставьте opening balance, proceeds нового периода, adjustments, closing balance и applied threshold. Если итог следующего statement начинается не с прежнего closing balance, задайте финансовой поддержке вопрос именно об этой разнице. Так магазин приложений получает проверяемый пример, а не предположение о пропавшей мелкой сумме.
Если proceeds ниже порога, отметьте переносимый остаток и следующий период. Не называйте его просроченным только потому, что продажа состоялась. Иная ситуация — прекращённый аккаунт, при котором новые продажи невозможны: тогда попросите пункт о final payout и судьбе остатка ниже обычного минимума. Магазин приложений должен ответить применимой процедурой, а не предложением внешнего «пополнения для активации вывода».
Договор, налоги и банк образуют три независимых допуска
Прямой ответ: наличие proceeds ещё не означает готовность payout, если платный договор не действует, tax forms не приняты или банковский профиль не завершён.
В App Store Connect проверьте Paid Apps Agreement и статус Business. Apple прямо связывает получение выплат с действующим платным договором, банковской информацией, налоговыми формами и порогом. В Google посмотрите merchant payments profile и verification. В RuStore сопоставьте реквизиты разработчика с договором и назначением предыдущих платежей. Для каждого допуска запишите не «вроде заполнено», а точный статус, дату изменения и сообщение о недостающем действии.
Не исправляйте всё одновременно. Смена банка после запуска обработки может попасть только в следующий цикл; обновление налоговой формы может вызвать отдельную проверку. Магазин приложений должен получить одно обращение с хронологией: когда proceeds закрылись, когда изменён профиль, что подтверждено и какой payout ожидается. Это позволяет отличить собственную незавершённую настройку от необъяснённого hold.
Налоговая форма не равна российскому налоговому расчёту
Прямой ответ: форма, которую просит иностранный магазин приложений, влияет на compliance и возможные удержания, но не заменяет учёт дохода в России.
Apple указывает необходимость tax forms в зависимости от страны аккаунта; Google Payments Center также собирает налоговые сведения merchant. Разработчик фиксирует название формы, статус принятия, дату и применённое withholding. Затем бухгалтер отдельно определяет российскую квалификацию дохода, курс, документы и возможное зачётное значение иностранного удержания. Не обещайте автоматический зачёт и не вычитайте одну сумму дважды.
Если payout меньше statement, запросите breakdown: proceeds, withholding tax, комиссия магазина приложений, банковские fees и currency conversion. Магазин приложений не обязан отвечать за налог либо комиссию, удержанную другим участником, но должен позволить связать собственный расчёт с отправленной суммой. В претензии спорьте только с необъяснённой разницей, а налоговый вопрос передайте профильному специалисту.
Банковские реквизиты проверяют посимвольно
Прямой ответ: большинство споров о возвращённом payout начинается с несовпадения имени владельца, номера, routing code, IBAN, страны или поддерживаемой валюты.
Сравните banking profile с официальной справкой банка и предыдущим входящим платежом. Учитывайте ведущие нули, отдельность IBAN и account number, точное имя account holder и branch country. Не публикуйте полный счёт в тикете без необходимости: достаточно маскированного значения, пока поддержка не предоставит защищённую форму. Если реквизиты менялись, сохраните дату одобрения новой записи и то, какой счёт был primary при обработке payout.
Apple предупреждает, что изменения после начала processing могут примениться в будущем цикле. Google в ряде стран просит верифицировать счёт банковской выпиской; официальная инструкция Google по verification допускает редактирование чувствительных полей при сохранении нужных данных. Магазин приложений не должен получать пароль от интернет-банка ради такой проверки.
Банк-посредник может уменьшить или задержать перевод
Прямой ответ: когда магазин приложений действительно отправил деньги, следующий разрыв ищут между его банком, intermediary bank и счётом разработчика.
Запросите payment date, amount, currency, beneficiary, последние цифры счёта и reference. Для wire могут понадобиться дополнительные сведения, доступные отправителю. Покажите банку разработчика именно эти параметры. Фраза «ищите долларовый перевод примерно на такую сумму» недостаточна после конвертации и fees. Если банк отклонил платёж, выясните reason code и дату возврата отправителю.
Официальный обзор получения выплат Apple прямо отмечает возможные комиссии банка разработчика и промежуточных финансовых учреждений. Поэтому разница между отправленной и зачисленной суммой не автоматически является удержанием Apple. Но магазин приложений должен подтвердить сумму, которую передал в банковскую цепочку.
Сверка строится от statement к банковской выписке
Прямой ответ: одна рабочая строка должна объяснять, из какого отчётного блока возникла сумма и в каком payout она была отправлена.
Не превращайте таблицу в копию всех выгрузок. Сначала сгруппируйте financial statement по периоду, валюте и приложению, а внутри сохраните ссылки на SKU или product ID. Возвраты и корректировки показывайте со знаком и типом операции. Потом добавьте payout reference и фактическое поступление. Если банк получил консолидированную сумму за несколько стран или приложений, один payout будет связан с несколькими строками proceeds.
| Слой | Ключ | Что проверяется | Типичный разрыв |
|---|---|---|---|
| Продажи | SKU / product ID | Quantity, sale, return, страна | Предварительная операция не попала в settlement |
| Statement | Период / валюта | Proceeds и корректировки | Hold, threshold, tax или незакрытый период |
| Payout | Payment reference | Дата, сумма, счёт получателя | Платёж не создан либо возвращён |
| Банк | Входящая операция | Зачисление, fee, conversion | Intermediary fee или банковское отклонение |
Магазин приложений получает вместе с тикетом не всю бухгалтерскую базу, а лист расхождений. Например: «statement 2026-07, EUR, proceeds 8 420; payout отсутствует; threshold пройден; banking active». Это намного полезнее скриншота с графиком и позволяет поддержке передать запрос финансовой команде без повторного сбора фактов.
Если хотите проверить структуру такой сверки до отправки, доступна бесплатная дистанционная консультация для разработчиков по всей России. Она проводится без гарантии выплаты или восстановления аккаунта. Получить консультацию
Договорное лицо устанавливают по каждому расчётному контуру
Прямой ответ: название App Store, Google Play или RuStore в интерфейсе не отменяет проверку компании, указанной в договоре и financial statement.
У международного магазина приложений договорное лицо может зависеть от страны разработчика, территории продаж и редакции agreement. Плательщиком конкретного payout может выступать не то же наименование, которое пользователь видит в каталоге. У российского сервиса дополнительно проверяют ИНН, соглашение о распространении и назначение предыдущего поступления. Поэтому в карте дела укажите: кто заключил договор; кто сформировал statement; кто значится отправителем в выписке; кому адресуется финансовый тикет.
Если магазин приложений поменял договорную структуру между двумя периодами, не объединяйте statements одной строкой. Отметьте дату перехода, новый vendor ID, переакцепт договора и остаток до миграции. Попросите письменно объяснить, был ли balance перенесён и какая компания отвечает за финальный расчёт старого контура. Такая проверка особенно нужна после реорганизации аккаунта, смены страны или перехода с физического лица на компанию.
Магазину приложений направляют требование в пределах принятой им роли. Если банковский платёж уже отправлен другим юридическим лицом группы, это не повод предъявлять одинаковую сумму всем участникам. В претензии допустима развилка: основной адресат подтверждает обязанность, а платёжное лицо предоставляет reference и сведения о возврате. Дублирование одного долга создаёт противоречивую позицию.
Финансовые роли и уведомления сохраняют отдельно от доступа к релизам
Прямой ответ: пользователь, который загружает сборки, не обязательно видит payments profile, налоговые формы и банковские события.
Составьте список ролей на дату последнего нормального payout и на дату сбоя. В App Store Connect отдельно важны Account Holder, Admin и Finance; в Google Payments Center существует собственный набор payments users; в RuStore финансовая переписка может идти на адреса, отличные от технических контактов приложения. Зафиксируйте, кто мог принять agreement, изменить банк, получить statement и прочитать уведомление о failed payout.
Проверьте почтовые фильтры и архив компании. Магазин приложений часто сообщает о новом отчёте, запросе tax information, проверке банка или отклонённой выплате письмом. Отсутствие письма у разработчика не доказывает, что уведомления не было у бухгалтерии. Одновременно письмо без записи в официальном кабинете нельзя считать достаточным: его домен и событие нужно сверить через самостоятельный вход.
Когда финансовый сотрудник уволился, магазин приложений должен получить запрос от действующего уполномоченного пользователя. Приложите документ о полномочиях через предусмотренную форму, а не пересылайте старые recovery codes. После восстановления роли выгрузите историю до любых массовых правок. Это помогает увидеть, не завис payout из-за неподтверждённого банковского изменения или письма, оставшегося в недоступном ящике.
Если доступ к payment profile принадлежит прежнему подрядчику, оформите передачу корпоративно и уведомите поддержку. Не пытайтесь «выкупить» пароль. Магазин приложений проверяет право Account Holder по своим данным; спор с подрядчиком об аккаунте может идти параллельно, но размер proceeds всё равно подтверждается statements и payout history.
Возвраты и chargeback уменьшают только связанные строки
Прямой ответ: уменьшение proceeds допустимо считать проверенным лишь тогда, когда видны тип корректировки, период и продукт, к которому она относится.
Return в финансовом отчёте может появиться позже исходной sale. Chargeback отражает спор по платёжной операции, а fraud adjustment — результат правил магазина приложений. Эти категории не всегда дают разработчику одинаковый объём данных, но магазин приложений должен позволить понять денежный эффект и исключить двойной вычет. Сведите количество возвратов по SKU и сравните их с изменением Extended Partner Share либо аналогичного поля.
Не требуйте персональные данные покупателя, если для проверки достаточно order reference, даты, страны и суммы. Не называйте каждый возврат мошенничеством со стороны витрины: пользователь действительно может получить деньги назад. Но общий ответ «корректировки безопасности» не объясняет, почему из payout исчез весь доход приложения при небольшой доле спорных операций. В таком случае предложите перечислить бесспорную часть и отдельно продолжить проверку выборки.
Подписки сверяют по продлениям, а не по числу активных пользователей
Прямой ответ: активная подписка не подтверждает, что очередное списание состоялось и стало закрытой расчётной операцией.
Для subscription product отделите начало подписки, trial, первое платное списание, renewal, billing retry, grace period, cancellation и refund. Магазин приложений может показывать пользователя активным в момент, когда деньги ещё не собраны или продление проходит retry. В financial statement попадёт иной набор событий, чем в продуктовой аналитике. Поэтому число subscribers нельзя умножать на цену и объявлять задолженностью.
Сверяйте product ID, тип предложения, страну, currency и sale/return. Если после изменения цены proceeds резко упали, проверьте, применялась ли старая цена к существующей когорте, действовали ли льготные периоды и как отражена комиссия. Для претензии выделите только строки, которые закрылись как оплаченные и не имеют подтверждённого возврата.
Конвертация объясняется отдельным курсом и датой
Прямой ответ: разница валют не должна исчезать в общей комиссии, потому что proceeds и банковское зачисление могут конвертироваться на разных стадиях.
В отчёте Apple есть Partner Share Currency; банк разработчика видит валюту входящего платежа и возможную конвертацию счёта. Google и другие магазины приложений также используют настройки merchant profile и доступные способы payout. Запишите исходную валюту proceeds, валюту платежа, валюту счёта, сумму до fees и сумму после зачисления. Если магазин приложений показывает applied exchange rate, сохраните его вместе с датой.
Рублёвый эквивалент для внутреннего управленческого отчёта не заменяет сумму договорного требования в валюте расчёта. Для российского учёта курс и дата определяются отдельно бухгалтером. В спорном листе достаточно показать: какая сумма заявлена витриной, сколько отправлено и сколько получил банк. Только необъяснённая разница адресуется оператору магазина.
Снятие приложения с публикации не равно закрытию выплат
Прямой ответ: удаление карточки или прекращение новых продаж нужно отделить от судьбы proceeds по ранее завершённым операциям.
Сохраните точную формулировку решения: rejected update, app removed, distribution unavailable, agreement terminated или account terminated. Эти статусы имеют разные последствия. Приложение может исчезнуть из магазина, пока developer account и финансовые отчёты остаются доступными. И наоборот, закрытие аккаунта может перекрыть вход к statements, хотя расчёт за прежний период ещё не завершён.
Постройте временную границу: последняя допустимая продажа, конец финансового периода, возможное окно refunds и дата termination. Магазин приложений вправе применять условия договора о корректировках, но разработчику нужен финальный statement: валовые закрытые строки, deductions, удержанный остаток, уже отправленные payouts и сроки следующего решения. Спор о правилах контента оформляйте отдельно, чтобы он не заслонил арифметику.
Termination требует финального расчётного отчёта
Прямой ответ: после прекращения договора первым требованием становится не немедленная выплата любой цифры, а документированная судьба каждой закрытой суммы.
Изучите termination clause: действует ли post-termination hold, возможен ли зачёт возвратов, как долго обрабатываются chargeback и куда направлять уведомления после закрытия кабинета. Не придумывайте универсальный срок. У Apple, Google Play и RuStore различаются договорные лица и процедуры. Магазин приложений может обоснованно удерживать часть под открытые операции, но должен отличить её от финально payable proceeds.
В письме перечислите периоды и валюты, приложите последние statements и попросите: final statement; перечень post-termination adjustments; основание и срок каждого hold; payout reference по отправленному; дату решения по остатку. Если договор позволяет выгрузку в течение ограниченного времени, сделайте её сразу. Если доступ уже закрыт, используйте адрес из уведомления и юридические реквизиты договора, а не аккаунт «помощника» в мессенджере.
При закрытом кабинете доказательства восстанавливают из четырёх источников
Прямой ответ: отсутствие входа усложняет расчёт, но не делает его невозможным, если сохранились письма, банковские поступления, бухгалтерские документы и файлы команды.
Проверьте почту Account Holder и Finance users: уведомления о reports, payout, tax и banking changes. В бухгалтерии найдите прежние акты, invoices и выписки. У разработчиков могут сохраниться автоматические выгрузки App Store Connect API или внутренние отчёты по order events. В системе доступа — список пользователей и дата последней смены ролей. Каждый файл отмечайте как первичный либо производный.
Затем запросите магазин приложений предоставить statements вне закрытого интерфейса. Назовите legal entity, vendor или merchant ID, package name, период и маскированный банковский счёт. Не выдавайте внутренний расчёт за официальный report. Если приходится строить оценку, покажите диапазон и пробелы. Для претензии лучше честный минимум по подтверждённым месяцам, чем крупная цифра из рекламного dashboard без settlement.
Чужая смена реквизитов переводит дело в инцидентную ветку
Прямой ответ: если primary bank account изменён неизвестным пользователем, сначала сохраняют историю доступа и спорный payout, а уже затем отзывают роли.
Зафиксируйте Finance/Admin users, email-уведомления, дату одобрения банковских данных, последние цифры старого и нового счёта, payout reference и время. Обратитесь в официальную поддержку с пометкой unauthorized change и попросите сохранить audit logs. Параллельно уведомите банк, если платёж уже ушёл. Не удаляйте сообщения и не переустанавливайте рабочее устройство до получения технической помощи: можно потерять доказательства входа.
Ключ подписи приложения и API secret не включаются в финансовую претензию. Их компрометацию рассматривают отдельно и заменяют штатной процедурой после фиксации. Магазин приложений не должен получать seed-фразу или банковский код — таких данных в этом сценарии вообще нет. Любой человек, который просит полный удалённый доступ для «возврата payout», создаёт вторичный риск.
Если payout уже отправлен, нужен банковский reference
Прямой ответ: статус paid проверяют не скриншотом, а набором реквизитов, по которым банк может найти или отклонить перевод.
Попросите дату value/payment, amount, currency, beneficiary bank, последние цифры account, reference и доступный trace. Сравните эти данные с banking profile, действовавшим на момент processing. Затем обратитесь в банк разработчика. Для EFT и wire сроки различаются; выходные и праздники тоже учитываются. Если банк нашёл платёж, но удержал compliance review, спор перемещается к банковской стадии.
Если перевод возвращён отправителю, запросите reason code и дату возврата. Следующее требование к витрине — обновить статус balance и назвать цикл повторного payout после исправления реквизитов. Не включайте возвращённую сумму одновременно как «не отправлено» и как банковский убыток. Магазин приложений должен видеть одну хронологию, а банк — только относимую к его стадии часть.
Если payout не создан, банк разработчика не поможет
Прямой ответ: отсутствие payout ID означает, что разрыв пока находится в договорной или расчётной системе витрины.
Проверьте пять блоков: closed statement; minimum threshold; agreement; tax; banking verification. Добавьте compliance hold и account termination, если они отображаются. Для каждого пункта приложите статус и дату. Не отправляйте в поддержку двадцать общих тикетов: один номер, один период, одно приложение и список приложений к обращению позволяют отследить ответ.
Если магазин приложений проверяет только часть операций, предложите выплатить сумму, которая остаётся payable даже по его версии. В альтернативном расчёте временно примите заявленные refunds и hold, не признавая их окончательно. Такой минимум снижает спор о размере. Если же statement ещё не закрыт или threshold не достигнут, зафиксируйте будущую контрольную дату вместо преждевременной претензии о просрочке.
Претензия магазину приложений начинается с номера отчёта
Прямой ответ: сильное требование называет конкретный statement, payout и отсутствующий переход, а не просит «вернуть монетизацию».
В шапке укажите юридическое лицо разработчика [ФИО], vendor/merchant ID, приложение и договорного контрагента. В хронологии — отчётный период, дату statement, выполнение threshold, статусы agreement/tax/bank и обращения. Расчёт приложите отдельным файлом: proceeds, подтверждённые deductions, отправленные payouts, остаток [сумма]. Требования формулируйте альтернативно: перечислить payable balance; предоставить breakdown; назвать основание и срок hold; сообщить банковский reference.
Проверьте адрес и процедуру в действующем договоре. Общую рамку денежных обязательств и способов защиты можно сверять по актуальному тексту Гражданского кодекса РФ, но российский кодекс сам по себе не устанавливает срок иностранной витрины и не решает вопрос применимого права. Для трансграничного договора заранее оцените подсудность и реальную исполнимость.
Перед отправкой можно бесплатно и дистанционно проверить расчёт и адресата по всей России. Это не обещание разблокировки: консультация проводится без гарантии взыскания proceeds. Получить консультацию
Документы передают по описи и без секретов
Прямой ответ: финансовой команде нужны statements и идентификаторы, а не полный доступ к developer account или исходному коду.
В описи укажите имя файла, период, источник, дату скачивания и назначение. Для financial report — валюту и приложение; для выписки — маскированный счёт и относимую строку; для договора — редакцию; для письма — технические заголовки или подтверждение доставки. Личные данные покупателей, посторонние приложения и банковские операции скрывайте в рабочей копии.
Никому не передавайте пароль, 2FA code, recovery code, signing key, приватный API key или доступ к интернет-банку. Официальная поддержка может попросить подтвердить Account Holder, но способ проверяется через домен и старый тикет. Магазин приложений располагает собственными order и payout records; требование «пришлите ключ подписи, чтобы увидеть баланс» не соответствует предмету финансовой сверки.
Индексные соседние статьи не меняют стороны спора
Прямой ответ: банковский и потребительский материалы второго круга полезны для навигации, но в них иные обязательства и доказательства.
Если банк неверно рассчитал доход по собственному продукту, откройте разбор о неначисленных процентах по накопительному счёту. Там нет app ID, proceeds и developer agreement. Если покупателю привезли товар не полностью, применима статья о неполном комплекте интернет-заказа, где важны состав товара и потребительская претензия.
Для самого разработчика могут пригодиться хронология дела и отдельный разбор невыплаченного гонорара на фриланс-бирже. Эти ссылки не превращают витрину в работодателя или банк. Магазин приложений остаётся стороной только в объёме своего договора, отчётности и расчётной роли.
Учебная история о закрытом fiscal month
Прямой ответ: первый составной учебный пример показывает, почему продажи последней календарной недели нельзя автоматически включать в уже просроченный payout.
Студия [ФИО] сравнила dashboard с июльским statement и решила, что недополучила 1,4 млн рублей. Построчная сверка показала три слоя: 820 тыс. рублей Extended Partner Share относились к закрытому fiscal month; 310 тыс. появились в последних календарных днях и вошли в следующий период; 270 тыс. составляли Customer Price до комиссии и налогов. Порог был пройден, договор и банковский профиль действовали.
Студия потребовала reference только по закрытым 820 тыс. и получила подтверждение, что payout ушёл на прежний primary account перед сменой реквизитов. Остальные суммы оставили следующему statement. История вымышленная, составлена для обучения чтению fiscal calendar и не прогнозирует результат конкретного обращения. Её смысл — не уменьшить требование произвольно, а выбрать созревший денежный слой.
Учебная история о termination и финальном statement
Прямой ответ: второй составной учебный пример объясняет, как отделить прекращение аккаунта от расчёта по прежним подписочным продлениям.
Аккаунт ИП [ФИО] был прекращён после спора о правилах контента. Доступ к приложению исчез, но на почте сохранились два statements, письмо о payout hold и список subscription product ID. Разработчик не потребовал весь estimated revenue. Он сложил закрытые proceeds, вычел видимые returns, отметил открытый период и запросил final statement, основание post-termination hold и календарь решения.
В ответ витрина раскрыла ещё один блок refunds и дату финального расчёта; часть удержания осталась спорной. История вымышленная и объединяет типовые отчётные события исключительно как учебную модель. Она не утверждает, что termination всегда оставляет payable balance или что любой hold незаконен. Вывод ограничен методикой: сохранить документы, разделить периоды и потребовать расшифровку.
Оценка позиции опирается на отчёт, статус и адресата
Прямой ответ: позиция сильнее, когда closed proceeds воспроизводятся, все обязательные профили активны и магазин не объясняет отсутствие payout.
50/50 — это редакционная оценка, а не статистика. Такой условный ориентир возможен, если financial statement закрыт, threshold пройден, agreement/tax/bank имеют рабочий статус, а ответ поддержки не содержит ни hold basis, ни payment reference. Перспектива слабее при опоре на gross dashboard, незаполненной tax form, неизвестной валюте, открытом отчётном периоде или споре с брендом вместо договорного лица.
Комментарий проверен модерацией сайта. Отдельно учитывайте иностранное право, termination clause, размер остатка, стоимость процесса и возможность исполнения. Ни представитель, ни посредник не может гарантировать выплату только по скриншоту proceeds.
Мошенническая «разблокировка» создаёт новую потерю
Прямой ответ: настоящий payout не требует перевода налога, депозита или AML-сбора на карту физлица либо неизвестный криптокошелёк.
Мошенник может знать название приложения и примерный balance из открытых данных или утечки. Он присылает копию интерфейса, предлагает «внутреннего менеджера» и просит войти по ссылке. Не отвечайте кодом, не устанавливайте удалённый доступ и не подписывайте неизвестные документы электронной подписью. Откройте официальный кабинет из закладки и найдите исходный тикет.
Если доплата уже сделана, сохраните переписку, реквизиты, чек, домен и время; срочно уведомите банк и подайте заявление по фактам перевода. Это отдельная потеря, которая не доказывает наличие исходного payout. Магазин приложений проверяет свою операцию по merchant/vendor ID, а не через оплату посреднику.
Финальный пакет читается без входа в кабинет
Прямой ответ: дело готово к передаче, когда другой специалист может повторить сумму и назвать пропавшую стадию, не получая пароль разработчика.
В папке должны быть agreement и его статус, tax/banking confirmation, sales reports, financial statements, описание полей, payout history, выписка, уведомление о termination, тикеты и расчёт [сумма]. На первой странице укажите четыре вывода: какой период закрыт; какие proceeds признаны; какой payout отсутствует; что именно требуется от юридического лица витрины. Пробелы перечислите отдельно.
Бесплатно разобрать такой пакет можно дистанционно по РФ; консультация помогает проверить statement, банковский reference и текст требования, но проводится без гарантии возврата денег. Получить консультацию