Откройте App Store Connect или Google Play Console, и вы увидите число, которое кажется вашей выручкой. В прошлом месяце там было 7 000. Ни одно из чисел не является неверным — но только одно из них должно быть отражено в вашем отчете о прибылях и убытках как "выручка". Ошибка в этом выборе может незаметно исказить вашу валовую маржу, неверно показать темпы роста и предоставить кредитору или инвестору искаженную картину вашего бизнеса.
Это вопрос "принципал против агента", и согласно стандарту признания выручки ASC 606 (US GAAP), это не необязательная формальность — это правило, которое определяет, отражаете ли вы 3 000 себестоимости продаж или просто $7 000 выручки без каких-либо дополнительных статей. Для независимого разработчика, продающего через App Store от Apple или Google Play Store, ответ обычно удивляет людей.
Вопрос, который рано или поздно задает каждый разработчик приложений
Триггер почти всегда одинаков: основатель собирает питч-дек, подает заявку на кредит для малого бизнеса или просто пытается ответить на вопрос "сколько я на самом деле заработал в этом квартале" и понимает, что все это время учитывал как "продажи" только то, что поступило на банковский счет. Эта сумма уже за вычетом комиссии Apple или Google — то есть доля платформы уже вычтена.
Проблема в том, что уменьшение выручки на сумму комиссии платформы — это не вопрос стиля. ASC 606 содержит специальный тест именно для такой ситуации, и он сводится к одному вопросу: кто контролирует продаваемый товар до того, как он переходит к покупателю?
Тест контроля ASC 606 простыми словами
Пятиэтапная модель выручки ASC 606 требует определить обязанности к исполнению в договоре и решить, кто их выполняет. Когда между вами и конечным клиентом находится маркетплейс или платформа — Apple, Google, Etsy, DoorDash, Uber — стандарты бухгалтерского учета называют это оценкой принципала против агента, и руководство PwC по выручке отмечает, что продажи в магазинах приложений являются классическим примером ситуаций, требующих такого тщательного анализа.
- Принципал: вы контролируете товар или услугу до ее передачи клиенту. Вы признаете полную, валовую сумму, уплаченную клиентом, как выручку, а комиссия платформы становится себестоимостью продаж (расходом), а не уменьшением выручки.
- Агент: платформа контролирует предложение, а вы просто организуете продажу от чужого имени. Вы признаете только чистую сумму, которую оставляете себе в качестве своего вознаграждения.
Три признака определяют, кем вы являетесь, согласно структурам Deloitte и PwC:
- Ответственность за выполнение — кто отвечает, если приложение не работает, подписка не предоставляется или клиент жалуется? Обычно это вы, разработчик, а не Apple.
- Риск до передачи — кто несет риск того, что "товарные запасы" (ваше приложение, ваш контент, ваш уровень подписки) не продадутся или не удовлетворят клиента? Опять же, обычно вы.
- Полномочия по установлению цены — кто определяет, сколько на самом деле платит клиент? Вы выбираете ценовой уровень своего приложения; платформа не обсуждает его с вами по каждой сделке.
Поскольку большинство независимых разработчиков контролируют пользовательский опыт продукта, владеют отношениями с клиентами по поддержке и обновлениям и сами устанавливают цены, они оказываются на стороне принципала по результатам теста — это означает, что правильным учетом будет отражать валовую сумму, уплаченную клиентом, как выручку, а долю Apple или Google учитывать как статью себестоимости, а не как невидимое удержание.
Цифры, стоящие за удержанием
Знать, что вы принципал, имеет смысл только если вы знаете, что именно вычитается. Структура комиссий платформ существенно изменилась за последние несколько лет, и большинство разработчиков все еще составляют бюджеты на основе устаревших предположений:
| Платформа | Стандартная ставка | Сниженная ставка | Кто имеет право |
|---|---|---|---|
| Apple App Store | 30% | 15% (Программа малого бизнеса App Store) | Разработчики с годовым доходом в App Store ≤$1 млн |
| Подписки Apple | 30% (1-й год) | 15% (со 2-го года) | Любая подписка после первых 12 месяцев |
| Google Play | 30% | 15% на первые $1 млн дохода в год | Все разработчики, применяется автоматически |
| Подписки Google Play | 15% фикс. | — | Весь доход от подписок |
| Apple ЕС (условия DMA) | ~17% + Core Technology Fee | до ~20% совокупно | Разработчики, выбравшие альтернативные условия ведения бизнеса в ЕС |
Плюс фиксированные ежегодные затраты, которые большинство забывает куда-либо отнести: ежегодный взнос разработчика Apple в размере 25. Небольшие суммы, но им тоже должно быть место в вашем плане счетов — обычно как общие операционные расходы, а не себестоимость продаж.
Правильный учет: практический пример
Предположим, клиент покупает внутриприложенческую подписку за 9.99 от клиента, оставляет себе 6.99 на ваш банковский счет. Учет $6.99 как "выручки" занижает вашу верхнюю строку на 30% — что имеет огромное значение, если вы сравниваете свой темп роста с конкурентом, продающим напрямую, или объясняете свою маржу кредитору.
Правильные проводки признают полную продажу, а затем отдельно отражают комиссию как расход:
2026-07-18 * "Apple" "iOS подписка — валовая продажа"
Активы:ДебиторскаяЗадолженность:AppStore 9.99 USD
Доход:ПродажиПриложений -9.99 USD
2026-07-18 * "Apple" "Комиссия App Store 30%"
Расходы:СебестоимостьПродаж:КомиссииПлатформ 3.00 USD
Активы:ДебиторскаяЗадолженность:AppStore -3.00 USD
2026-07-20 * "Apple" "Получена выплата"
Активы:РасчетныйСчет 6.99 USD
Активы:ДебиторскаяЗадолженность:AppStore -6.99 USDОбратите внимание, что счет дебиторской задолженности обнуляется после получения выплаты, но ваш отчет о прибылях и убытках по-прежнему показывает 3.00 себестоимости — валовую маржу в 70% по этой продаже, а не загадочно исчезнувшие 30%. Это именно тот тип транзакций, с которым хорошо справляются текстовые, версионируемые бухгалтерские книги: валовая продажа, комиссия платформы и выплата — это три отдельных, проверяемых события, а не одно размытое банковское поступление.
Почему числа из панели управления недостаточно
Даже зная правило, применять его вручную сложнее, чем кажется. Стандартные отчеты App Store Connect и Play Console показывают агрегированные итоги, а не детализацию по подписчикам и транзакциям, которую теоретически требует ASC 606 — поступления, возвраты и конвертация валют часто объединяются в одну общую сумму через несколько дней или недель после фактической продажи. Именно этот разрыв является причиной того, что все больше компаний, работающих по подписке, используют API платформ или такие инструменты, как RevenueCat, для восстановления детализации по транзакциям, вместо того чтобы пытаться восстановить ее из ежемесячного сводного PDF.
Игнорирование этого шага имеет реальную цену. Один широко цитируемый пример: разработчик увидел на панели управления 1 294 — разрыв более 60% между "выручкой", которую, как он думал, он получил, и тем, что бизнес на самом деле сохранил. Разработчики, принимающие решения о найме или расходах на основе числа из панели управления, а не сверенной суммы, составляют бюджет на основе цифры, которая никогда не была реальной.
Распространенные ошибки, искажающие вашу отчетность
- Учет только чистого депозита как выручки. Это самая распространенная ошибка, и именно о ней эта статья — она занижает как выручку, так и себестоимость продаж, делая картину валовой маржи бессмысленной.
- Игнорирование возвратов и чарджбэков. Apple и Google обрабатывают возвраты средств клиентам от вашего имени, иногда через несколько недель после первоначальной продажи — если вы не сверяете данные по транзакциям, возвращенная выручка может бесконечно висеть в ваших книгах.
- Отнесение ежегодного взноса разработчика Apple (25) в себестоимость продаж. Это фиксированные операционные расходы, а не комиссии на уровне транзакций — они должны относиться к другой категории расходов.
- Забывание отдельного графика комиссий для ЕС. Если какая-либо часть вашей пользовательской базы находится в ЕС и вы выбрали альтернативные условия Apple, эта выручка имеет другую структуру комиссий, чем остальная часть вашего бизнеса, и требует отдельного счета.
Держите свои финансы в порядке по мере масштабирования
Будь вы индивидуальным разработчиком с одним приложением в магазине или управляете небольшой студией с несколькими подписочными продуктами, решение "gross vs net" накапливается каждый месяц, когда вы ошибаетесь — к тому времени, когда вы привлекаете раунд или подаете заявку на финансирование, заниженная строка выручки — это то, что трудно объяснить. Beancount.io предоставляет разработчикам текстовую, версионируемую бухгалтерскую книгу, созданную именно для таких многоэтапных транзакций — валовая продажа, комиссия платформы и выплата как три отдельные, проверяемые записи вместо одного размытого банковского депозита. Начните бесплатно и убедитесь, почему разработчики, которые уже мыслят кодом, предпочитают бухгалтерию, которая работает так же.