Бухгалтерия разработчика Chrome-расширений: сверка выплат после того, как Google отказался от встроенных платежей

Откройте сегодня панель разработчика Chrome Web Store — и заметите, что кое-чего не хватает: вкладки «платежи». Google закрыл собственную систему платежей внутри расширений ещё в 2021 году, и она так и не вернулась. Если вы хотите взимать плату за Chrome-расширение в 2026 году, вам придётся самостоятельно разбираться с биллингом, подписками, возвратами, сбором налогов и — с тем, о чём почти никто не задумывается заранее, — сверкой того, что реально поступило на банковский счёт, с тем, что было продано.

Именно эта часть подводит независимых разработчиков чаще, чем ценообразование. Разработчик-одиночка, ведущий три-четыре расширения через Stripe, Paddle или обёртку вроде ExtensionPay, в итоге получает выплаты, которые не сопоставляются напрямую ни с одним конкретным продуктом, всплески возвратов, возникающие из ниоткуда после задержки модерации в Chrome Web Store, и остаток на счёте, который никогда не совпадает с тем, что показывает панель продаж. Ничего из этого не является ошибкой в вашем бизнесе. Это предсказуемый результат самостоятельной сборки платёжного стека, который раньше обслуживал Google.

Вот как выстроить учёт, который это выдержит.

Почему Google ушёл из платёжного бизнеса​

Chrome Web Store Payments запустился в начале 2010-х годов, когда у разработчика-одиночки было не так много хороших вариантов брать плату за браузерное расширение. К 2021 году Stripe, Braintree и волна сервисов «продавца по договору» (merchant of record) созрели настолько, что Google решил, что ему больше не нужно вести собственную систему оформления заказа, лицензионных ключей и выплат. Компания отказалась от Chrome Web Store Payments и предложила каждому платному расширению выбрать: либо стать бесплатным, либо перейти на стороннего процессора.

Практический результат для разработчиков: каждый доллар, заработанный расширением, теперь проходит через платёжный стек, который вы собрали сами, и каждую проблему сверки, которую этот стек создаёт, вам приходится решать самостоятельно. Больше не существует единого «отчёта о выплатах Chrome Web Store» — есть то, что даёт ваш процессор, плюс то, что показывает собственная аналитика листинга Chrome Web Store, плюс банковская выписка, и эти три источника редко совпадают с первого взгляда.

Платёжный процессор или продавец по договору — выберите один вариант для каждого расширения​

Прежде чем начинать сверку, нужно понять, на какой стороне сделки вы находитесь юридически, потому что от этого зависит, что попадёт в ваш учёт.

Платёжный процессор (напрямую Stripe или обёртка поверх него вроде ExtensionPay) делает продавцом вас. Вы получаете деньги, вы являетесь продавцом по договору для целей налогообложения, и именно вы отвечаете за определение обязательств по налогу с продаж и НДС в каждой юрисдикции, где живёт клиент. Комиссии ниже — базовая ставка Stripe составляет 2.9% + $0.30 за платёж, а обёртка вроде ExtensionPay обычно добавляет сверху свою долю, — но всё бремя соблюдения требований лежит на вас.

Продавец по договору (Merchant of Record — Paddle, Lemon Squeezy, Fungies и подобные) юридически становится продавцом вместо вас. Такой сервис собирает НДС или GST, подаёт декларации в более чем 140 странах, которые теперь требуют этого для цифровых товаров, обрабатывает чарджбэки и выплачивает вам чистую выручку. Вы отдаёте 4–8% выручки вместо примерно 3%, но целая категория учётной и налоговой работы исчезает. Подробный разбор компромиссов и того, как посчитать, когда переход окупается, смотрите в нашем руководстве по продавцу по договору.

Для большинства независимых разработчиков расширений с доходом ниже нескольких тысяч долларов в месяц дополнительные 3–5%, которые берёт MoR, — это дешёвая страховка от необходимости вручную регистрироваться для уплаты НДС в десятке стран. Как только у вас появляется реальная регулярная выручка сразу по нескольким расширениям, пересчитайте это сравнение заново — по мере роста объёма математика меняется.

Что бы вы ни выбрали, зафиксируйте это письменно. Ваш учёт должен давать чёткий ответ на вопрос «кто юридически является продавцом-регистрантом для этого расширения», потому что от этого зависит, появится ли вообще обязательство по налогу с продаж на вашем балансе.

Проблема сверки структурна, а не случайна​

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

• Пакетные выплаты. Stripe и большинство MoR выплачивают деньги по скользящему графику (часто через 2–7 дней после списания, иногда еженедельно), поэтому выплата, поступившая 5-го числа месяца, содержит продажи за последние несколько дней предыдущего месяца. Если вы учитываете выплаты как выручку в день их поступления на счёт, вы каждый месяц ошибочно относите доход не к тому периоду.
• Несколько расширений на одном аккаунте процессора. Если вы ведёте несколько расширений через один и тот же аккаунт Stripe или Paddle — обычная ситуация для разработчиков, выпускающих набор небольших инструментов, а не один флагманский продукт, — выплата представляет собой единую сумму, покрывающую их все. Без разметки по каждому расширению (поля метаданных Stripe или отдельные продукты/цены для каждого расширения) невозможно понять, какое расширение на самом деле принесло выручку, а значит, невозможно понять, какое из них стоит вашего времени на поддержку.
• Комиссии, возвраты и конвертация валюты уже вычтены до того, как вы увидите итоговую цифру. Сумма выплаты уже указана за вычетом комиссий за обработку, любых возвратов, оформленных за этот период, и конвертации валюты, если вы продаёте на международном рынке. Учёт выплаты как валовой выручки завышает верхнюю строку отчёта и скрывает реальную маржу.

Решение — трёхсторонняя сверка, выполняемая как минимум ежемесячно:

1. Отчёт о продажах процессора — валовые транзакции, при возможности с разбивкой по продукту/расширению, до вычета комиссий и возвратов.
2. Отчёт о выплатах процессора — чистые суммы, реально поступившие на ваш счёт, с комиссиями и возвратами, выделенными отдельными строками.
3. Банковская выписка — депозиты, которые действительно прошли.

Сопоставьте все три. Отчёт о продажах показывает, сколько вы заработали (выручка, признанная в момент, когда клиент заплатил за период обслуживания). Отчёт о выплатах показывает потери на комиссиях и активность по возвратам, которые нужно учитывать как расходы и контр-выручку. Банковская выписка подтверждает, что деньги действительно поступили. Когда любые два из трёх источников не сходятся, это сигнал, что нужно разобраться — неудавшаяся выплата, оспариваемый чарджбэк или неожиданная комиссия процессора.

Специфический риск Chrome: задержки модерации и снятие с публикации​

У любого платёжного стека есть обычная активность по возвратам. У Chrome-расширений есть дополнительный сценарий отказа, который стоит отслеживать как отдельную статью: задержки модерации и снятие с публикации по решению Chrome Web Store.

Когда команда модерации Google помечает опубликованное расширение за нарушение политики, вы получаете либо немедленное снятие с публикации (при умеренных и серьёзных нарушениях), либо предупредительный период примерно в 7–30 дней на исправление незначительного нарушения. В любом случае пользователи теряют доступ к расширению, за которое активно платят, а это порождает предсказуемый всплеск запросов на возврат, чарджбэков и обращений в поддержку — разработчики сообщали о потере двузначного процента месячной выручки от подписок именно из-за такого сценария, помимо прямых возвратов.

Две учётные привычки превращают это из неожиданности в управляемую ситуацию:

• Помечайте возвраты и чарджбэки по причине. Возврат, потому что клиенту не понравилось расширение, — это обычные издержки ведения бизнеса. Возврат, потому что ваше расширение сняли с публикации на неделю, — это отдельный, отслеживаемый бизнес-риск. Разделение этих категорий (даже просто поле для заметок или субсчёт) позволяет за год увидеть, какая доля волатильности выручки связана с риском платформы, а какая — с соответствием продукта рынку.
• Относитесь к незакрытой проверке модерации или открытому предупреждению о нарушении политики как к событию, требующему раскрытия, точно так же, как вы бы отметили риск ухода ключевого клиента. Если вы считаете цифры, чтобы решить, поднимать ли цены, нанимать ли помощника или брать ли кредит, расширение, находящееся под 30-дневным предупреждением о соответствии, — это не «стабильная регулярная выручка»: моделируйте её как рискованную, пока проверка не будет пройдена.

Признавайте выручку тогда, когда её зарабатываете, а не когда поступает выплата​

Подписочные расширения и расширения с разовой покупкой требуют разного учёта, и путаница между ними — самая распространённая бухгалтерская ошибка в этой нише:

• Ежемесячные или годовые подписки: признавайте выручку равномерно за период, за который платит клиент, а не всю сразу в момент списания. Годовой план, оплаченный авансом, создаёт обязательство по отложенной выручке — вам уже заплатили, но вы ещё не предоставили одиннадцать из двенадцати месяцев обслуживания, поэтому в месяце продажи выручкой является только 1/12, а остальное списывается с баланса месяц за месяцем.
• Пожизненные тарифы (популярная модель ценообразования именно для расширений, поскольку пользователи настороженно относятся к постоянным подпискам за браузерный инструмент): такой тариф всё равно представляет собой бессрочное обязательство предоставлять обновления и поддержку, поэтому признание 100% денежных средств как выручки в первый же день завышает реально заработанный доход за этот месяц. Более обоснованный подход — признавать выручку от пожизненного тарифа за разумный расчётный период обслуживания (многие компании используют в качестве ориентира 12–36 месяцев), а не всю сразу.
• Разовые покупки без длящихся обязательств: признавайте выручку полностью в момент поставки — это простой случай.

MRR (ежемесячная регулярная выручка) — полезная метрика роста, но это не та же цифра, что признанная выручка в вашем учёте. MRR показывает темп активных подписок; ваш учёт должен отражать то, что вы реально заработали за этот период после учёта отложенной выручки.

Структура учёта, которая выдерживает несколько расширений​

Если вы ведёте учёт в текстовой системе двойной записи, решение проблемы «одна выплата, несколько расширений» — план счетов, который с самого начала разделяет доход по продуктам, плюс явные счета для вычетов, которые уже учтены в отчёте о выплатах:

2026-07-05 * "Stripe payout - batch #4471"
  Assets:Bank:Checking                      842.17 USD
  Income:Extensions:FocusTimer             -510.00 USD
  Income:Extensions:TabArchiver            -390.00 USD
  Expenses:PaymentProcessing:StripeFees      41.83 USD
  Expenses:Refunds:FocusTimer                16.00 USD

Каждая выплата становится одной транзакцией, которая сверяет банковский депозит с доходом по каждому расширению, комиссиями и возвратами как отдельными проводками — вместо одной непрозрачной строки «депозит Stripe», которая ничего не говорит о том, какой продукт на самом деле прибылен. Поскольку файл текстовый, вы можете искать в нём или запрашивать данные по расширению, по месяцу или по причине возврата — именно ту прозрачность, которую не даёт отчёт о выплатах одной суммой.

Ежемесячный чек-лист​

1. Выгрузите отчёт о продажах процессора за месяц (валовые суммы, по возможности с разбивкой по продукту).
2. Выгрузите отчёт о выплатах и выделите комиссии, возвраты и чарджбэки в отдельные строки.
3. Сверьте депозиты выплат с банковской выпиской.
4. Учитывайте выручку по подпискам и пожизненным тарифам по графику признания, а не в момент поступления.
5. Помечайте любой возврат, связанный с задержкой модерации или снятием с публикации в Chrome Web Store, отдельно от обычного оттока клиентов.
6. Если вы продаёте на международном рынке через прямого платёжного процессора (а не через MoR), проверяйте, не превысили ли ваши совокупные продажи в какой-либо стране порог регистрации по НДС/GST.

Ведите учёт своего бизнеса с расширениями так же чисто, как код​

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