App Store Connect показывает, что вы продали в прошлом месяце на 3 108. Вы суммируете, радуетесь 6 580 от Apple и $2 210 от Google. Никто вас не обманул. У каждого пропавшего доллара есть имя: НДС, комиссия, возвраты, налоговый зачет, конвертация валюты и, наконец, подоходный налог. Проблема не в самой разнице — а в том, что у большинства инди-разработчиков нет учета, который объяснял бы эти цифры, поэтому они не могут ответить на три по-настоящему важных вопроса: правильно ли я устанавливаю цены? Начисляю ли я правильную комиссию? Реален ли мой прогноз денежного потока?
В этом руководстве рассматривается весь путь от цены до конечного дохода, объясняется, почему выплата никогда не совпадает с отчетом, и предлагается ежемесячная процедура сверки, которая займет около 30 минут после настройки.
Три цифры, три разных ответа
У любого приложения есть три показателя дохода, и именно их смешение порождает путаницу:
- Валовая выручка — сколько заплатили клиенты, как показано на панели аналитики. Это цифра для хвастовства. Она включает налог, который взимает магазин, и обычно является ориентировочной, а позже уточняется.
- Доход разработчика — сколько, по данным магазина, вы заработали, согласно ежемесячным финансовым отчетам (Apple) и отчетам о доходах (Google). Это сумма за вычетом комиссии, налогов, которые магазин собирает и перечисляет, возвратов и возвратных платежей. Именно на эту цифру следует опираться в бухгалтерском учете.
- Выплата — банковский депозит. Это доход за вычетом налогов у источника, с учетом конвертации валюты, минимальных порогов выплат и платежного календаря магазина.
Если вы записываете только банковский депозит, ваш доход занижается и сдвигается на месяц или больше. А если записываете валовые продажи — он завышается на 30–50% и не совпадает с реально полученными деньгами. Все искусство учета в магазинах приложений — связать эти три цифры, чтобы каждый месяц сходился баланс между отчетным доходом и полученными деньгами.
Как формируется доход от цены до вычета
Возьмем подписку за €9,99, проданную в стране с 20% НДС и стандартной комиссией 30%. Вот честная картина:
| Шаг | Расчет | Остаток | % от цены |
|---|---|---|---|
| Заявленная цена | — | €9,99 | 100% |
| НДС, взимаемый и перечисляемый магазином | €9,99 ÷ 6 | €8,33 | 83% |
| Комиссия магазина (стандартная) | 30% × €8,33 | €5,83 | 58% |
| Возвраты и отмены (предположим, 3%) | 3% × €5,83 | €5,65 | 57% |
| Подоходный налог по ставке 30% | 30% × €5,65 | €3,96 | 40% |
Примерно 60% заявленной цены никогда не попадает к вам в карман. Продажи в США в штате, где нет налога на цифровые товары, начинаются с более высокой базы, а разработчик, платящий сниженную комиссию, получает значительно больше (та же продажа в регионе с НДС при комиссии 15% приносит €7,08 до вычета возвратов — около 71% от цены). Точный процент зависит от структуры ваших продаж, но структурный урок остается неизменным: валовая выручка — не ваши деньги. Это средства магазина, проходящие через ваш дашборд.
Никакой тайны здесь нет. Условия программы Apple и Google прямо описывают все вычеты. Не хватает только учета: места, где каждый слой этой воронки был бы зафиксирован и проверяем, а не был бы ежемесячным сюрпризом.
Какую комиссию вы на самом деле платите
Самая дорогостоящая ошибка в этом бизнесе — быть на неправильной ставке. Оба магазина вдвое снижают комиссию для небольших разработчиков, но регистрация не везде автоматическая:
Программа для малого бизнеса App Store от Apple снижает комиссию с 30% до 15% на платные приложения, внутриигровые покупки и подписки. Право на участие определяется в доходах — продажи за вычетом комиссии Apple, некоторых налогов и корректировок, а не валовая сумма — и требует, чтобы вы заработали не более 1 млн за текущий период. Две детали часто вводят в заблуждение:
- Если в середине года вы пересекаете отметку в $1 млн, стандартная ставка 30% применяется к будущим продажам — уже совершенные по ставке 15% не пересматриваются, а в следующем году снова можно подать заявку.
- Изменение ставки вступает в силу через 15 дней после окончания фискального месяца, в котором была одобрена ваша регистрация. Так что задержка с подачей заявки обходится дорого с каждой неделей ожидания.
Сниженная ставка Google Play применяет 15% к первым $1 млн дохода за календарный год, ставка 30% применяется к сумме выше этого лимита — для этого нужно объединить связанные аккаунты в Play Console и принять условия. Стоит отметить структурное отличие: в Google для всех подписок с автоматическим продлением с первого дня взимается комиссия 15% независимо от участия в программе. По стандартной ставке Apple подписчик платит 30% в первые 12 месяцев и 15% со второго года — веский аргумент в пользу удержания клиентов, который станет важен только после выхода из льготной программы.
Если вы зарабатываете менее $1 млн и не участвуете в программе Apple, исправить это — вероятно, самая выгодная десятиминутная инвестиция в году: форма заявки находится в App Store Connect в разделе «Соглашения, налоги и банковское обслуживание».
Почему депозит никогда не совпадает с отчетом
Даже при правильной ставке доход и выплаты расходятся по сугубо механическим причинам — и каждая заслуживает отдельной строки в вашем учете:
Платежные календари не совпадают с календарными месяцами. Apple выплачивает в течение 45 дней с конца каждого финансового месяца, который не совпадает с календарным — финансовый месяц может закончиться 27 декабря, а оплата придет 29 января. На практике разрыв составляет около 33 дней. Google платит 15-го числа следующего месяца (сдвигая на следующий рабочий день, если 15-е выпадает на выходные). Если вы работаете по методу начисления, доход декабря — это январские или февральские деньги, и для моста между ними нужен расчетный счет.
Минимальные пороги задерживают небольшие выплаты. Apple выплачивает только после превышения минимального порога, который зависит от страны и валюты банковского счета. Медленный месяц может означать, что депозита не будет вовсе, а остаток перейдет на следующий месяц — что выглядит как пропажа $30, если за этим не следить.
Возвраты и возвратные платежи вычитаются до выплаты дохода. Магазины списывают полную стоимость транзакции, а частота возвратов тихо меняется в зависимости от товара и региона. При правильном учете это уменьшение дохода в том месяце, когда возврат отражен в отчете, а не загадочный вычет из выплаты.
Налоги идут двумя разными путями. По НДС и многим налогам с продаж магазины выступают налоговыми агентами — например, в ЕС Google начисляет, взимает и перечисляет НДС, поэтому ваш доход не облагается налогом в этих странах. Отдельно: у неамериканских разработчиков возникает налог у источника с любых сумм, полученных из США, который может достигать 30%, если не заполнена форма W-8BEN или W-8BEN-E в App Store Connect (или аналог в Play Console). Соглашения об избежании двойного налогообложения — или просто тот факт, что выплаты часто идут из международных подразделений магазинов — могут свести эту ставку к нулю. В любом случае налог у источника выглядит как разрыв между отчетным доходом и депозитом, и, как правило, его можно вернуть, если задокументировать.
Конвертация валюты — это реальные расходы. Магазины выплачивают в валюте вашего банковского счета, конвертируя доход по отдельным территориям. Валютный спред — это расходы без счета, которые можно заметить, только сравнив отчетный доход в каждой валюте с депозитом.
Самый сложный вопрос бухучета для инди
Какой должна быть ваша выручка — валовая или чистая? Для подавляющего большинства инди-разработчиков ответ — чистая. Согласно стандартам признания выручки (ASC 606 в US GAAP и IFRS 15), решающим является то, являетесь ли вы принципалом в сделке — контролируете ли товар или услугу до передачи покупателю — или агентом, чьи обязательства считаются выполненными, когда магазин совершает продажу. Если магазин является торговой площадкой, собирает налоги, управляет платежами, несет ответственность за возвраты и платит вам чистую сумму с операции, то именно магазин — принципал, а ваша выручка — это ваш доход. Показывать валовую и списывать комиссию как расход — значит завышать выручку, искажать любые маржинальные коэффициенты и неверно отражать налоги, если кто-то когда-нибудь это увидит.
Вторая ошибка — это привязка по времени: отражение банковского депозита как выручки за текущий месяц. Депозит покрывает предыдущий месяц (или финансовый месяц). Правильный подход:
- Начисляйте выручку в момент продажи, используя оценки магазина, если фактические данные еще не поступили.
- Сверяйте с фактическими данными, когда поступит ежемесячный финансовый отчет, отражая разницу (она почти всегда есть — сказываются курсы валют, возвраты и корректировки).
- Закрывайте депозит по дебиторской задолженности с поступлением выплаты, а разницу (удержанный налог, валютные курсы, пороги) относите на отдельные счета.
Последний пункт — и есть суть: когда на каждый остаток есть отдельный счет, отличная от нуля разница не может остаться незамеченной и объясняется за несколько минут.
Ежемесячная 30-минутная сверка
- Скачайте фактические данные. Загрузите ежемесячный финансовый отчет из App Store Connect (подробный, по всем территориям, с датами расчетов). Из Play Console скачайте отчет о доходах. Это — источник данных, а не панели аналитики.
- Запишите доход по территориям и валютам. Одна строка выручки за магазин, с детализацией по территориям и валютам. Здесь хранится аудиторский след: когда нужно будет объяснить, почему европейский доход в марте упал на 12%, у вас будет разбивка по НДС, комиссиям и возвратам, а не единая цифра.
- Внесите корректировку «оценка-факт». Разница между тем, что показывал дашборд, и данными отчета: обычно возвраты, курс и массовые корректировки выплат.
- Учитывайте возвраты и возвратные платежи как уменьшение дохода в месяце отчета и следите за динамикой: растущий процент возвратов — это сигнал о проблеме, замаскированный под бухгалтерию.
- Сверяйте выплату с дебиторской задолженностью. Когда приходит депозит, сопоставляйте его с отчетом. Удержанный налог относите на счет налоговых активов (его часто можно зачесть); курсовые разницы — на валютные расходы; недоплату от минимального порога оставляйте на расчетном счете до следующего месяца.
- Ежеквартально проверяйте ставку комиссии. Сверяйте участие в программе для малого бизнеса в App Store Connect и свой тариф в Play Console — особенно если приближаетесь к $1 млн, ведь оба магазина меняют ставку для будущих продаж. Стройте модель до перехода: пересечение этой отметки может пересмотреть всю вашу маржинальную структуру в середине года.
Шесть шагов, один раз в месяц. Награда — не просто чистая отчетность, а то, что ценообразование, выбор тарифов и прогнозирование денежного потока наконец-то основаны на реальных цифрах.
Отслеживайте весь поток в текстовом формате
Именно для такой многоуровневой сверки текстовая бухгалтерия незаменима. В реестре Beancount каждому уровню воронки можно дать отдельный счет — income:appstore:ios, income:playstore:android, expenses:refunds, assets:receivable:payouts:apple, assets:tax-withheld — и ежемесячная запись станет вашим объяснением, а каждая цифра будет вести к скачанному отчету, который можно воспроизвести даже годы спустя. Поскольку реестр — это текст, отчеты магазинов могут лежать рядом в системе контроля версий, и процесс сверки превратится в diff, а не в раскопки в электронных таблицах. Если хотите автоматизировать импорт банковских выписок и данных магазина, в документации подробно описан конвейер импорта.
Упростите управление своими финансами
Доход от магазинов приложений — это тот вид договоренностей, где все выстроено против разработчика: комиссии, налоги, возвраты и платежные календари — все уменьшают выплаты до того, как они до вас дойдут. Ведение учета, повторяющего эту структуру, — вместо простой строчки «доход от приложений» — превращает запутанные выплаты в прозрачную, проверяемую систему. Beancount.io — это текстовая бухгалтерия с открытым исходным кодом, прозрачная, версионируемая и готовая к работе с ИИ. Каждый отчет, корректировка и выплата всегда прослеживаются. Начните бесплатно и сделайте свой доход таким же понятным, как код.