Ваши январские выплаты пришли от Lemon Squeezy, а августовские приходят от Paddle, и теперь бухгалтер задаёт вопрос, на который ни одна из панелей управления не ответит в одиночку: сколько выручки по подпискам вы фактически заработали за этот год? Старый провайдер собирал платежи по одной тарифной сетке, с одной периодичностью выплат и с одним набором налоговых счетов-фактур, выставляемых от его собственных юридических лиц. Новый провайдер делает ту же работу, но с другими отчётами, другими строками комиссий и другими документами. Между ними лежит остаток отложенной выручки, стопка годовых планов, проданных на одной платформе и обслуживаемых на другой, и закрытие года, которому нужно сшить два несовместимых регистра в один правдоподобный комплект отчётности. Именно это сшивание — а не интеграция API, которая занимает дни, — тихо проваливает миграции merchant of record.
Это живое решение для тысяч продавцов прямо сейчас. Stripe приобрела Lemon Squeezy в июле 2024 года, а январское обновление Lemon Squeezy 2026 года сообщило, что её будущее — это простой путь миграции на Stripe Managed Payments, собственный продукт Stripe в роли merchant of record. Крайний срок не опубликован, и Lemon Squeezy по-прежнему работает, но продавцы, которые не хотят мигрировать по чужому графику, оценивают независимых игроков: Paddle и Polar — оба настоящие merchant of record с одинаковой заявленной ставкой 5 процентов плюс 50 центов. Если вы один из них, переключение биллинга — простая часть. Сохранение достоверности отчётности на протяжении всего перехода — вот настоящий проект.
Что такое merchant of record на самом деле для вашей отчётности
Merchant of record — это юридический продавец вашего продукта, а не просто ваш платёжный процессор. Когда клиент покупает через Paddle, Polar или Lemon Squeezy, в выписке по карте указан провайдер, налоговый счёт-фактура выставляется от одного из юридических лиц провайдера, а регистрации по налогу с продаж и НДС в Германии, Японии или Техасе принадлежат провайдеру, а не вам. Провайдер рассчитывает, собирает, подаёт и перечисляет налог, берёт на себя ответственность по чарджбэкам и отправляет вам выплату за вычетом всего этого.
Эта юридическая структура определяет, как выглядят ваши бухгалтерские записи. Счёт-фактура покупателю документирует продажу провайдера вашему клиенту — это его счёт, а не ваш. Ваша сторона сделки документируется записями со стороны продавца: обратным счётом-фактурой, описывающим вашу поставку провайдеру, и уведомлением о переводе, фиксирующим сумму каждой выплаты. Ваша выручка — это выплата за вычетом комиссии провайдера, поступающая по графику провайдера, а не непрерывно. Документы каждого провайдера выглядят по-разному — именно поэтому использование двух из них в одном году раздваивает ваши записи.
Решение «брутто или нетто», которое нужно принять один раз
Прежде чем трогать любую из платформ, определитесь с единственной учётной политикой, которую заставляет вас защищать миграция: признаёте ли вы в качестве выручки полную сумму, уплаченную клиентом (брутто), или только полученную выплату (нетто)?
По ASC 606 это вопрос «принципал против агента», и ответ на него определяется контролем — а не тем, кто выставил счёт-фактуру или чьё имя указано в выписке по карте. Руководство содержится в ASC 606-10-55-36 по 55-40: организация является принципалом, если она контролирует указанный товар или услугу до их передачи клиенту, и отражает выручку в брутто; если её обещание состоит лишь в том, чтобы организовать предоставление товара или услуги другой стороной, организация является агентом и отражает только свою комиссию или вознаграждение в нетто. Для разработчика ПО, продающего через merchant of record по модели реселлера, тот же анализ определяет, кто ваш клиент. Если ваш клиент — конечный пользователь, выручка равна цене для конечного пользователя, а доля провайдера — это расход на продажу ниже строки выручки. Если ваш клиент — сам провайдер, выручка равна цене, которую провайдер вам заплатил, — то есть выплате.
Валовая прибыль в обоих случаях одинакова. Отражённая выручка — нет, и это число влияет на темпы роста, мультипликаторы выручки при привлечении финансирования или приобретении и на каждое сравнение период к периоду, которое читает ваш совет директоров. Большинство разработчиков ПО, продающих через маркетплейсы и реселлеров, приходят к учёту в брутто, но любой из ответов защитим, если ваш анализ его подкрепляет. Что не защитимо — это дрейф: отражение выплат Lemon Squeezy в нетто в первой половине года и выплат Paddle в брутто во второй, потому что отчёты нового провайдера упростили брутто. Выберите одну политику, зафиксируйте анализ контроля в записке, понятной вашему аудитору, и применяйте её одинаково к выплатам обоих провайдеров за весь год.
Пять швов, по которым год раздваивается
1. Подписки не мигрируют; клиенты переподписываются. Автоматического переноса токенов между платёжными процессорами не существует. Сохранённые карты, как правило, нельзя выгрузить из merchant of record в пригодной для использования форме, поэтому планируйте, что подписчикам придётся заново ввести платёжные данные на новой платформе, — или получите письменное подтверждение до принятия обязательств, что новый провайдер может перенести активные подписки и сохранённые карты за вас. Пока каждый клиент не переподпишется, старая платформа продолжает выставлять ему счета, а значит, обе системы работают параллельно месяцами, и закрытие каждого месяца сверяет два потока выплат.
2. Унаследованные цены и якоря продления нужно воссоздавать вручную. Каждая активная подписка несёт цену, дату продления и часто унаследованный тариф, который больше не продаётся. Новая платформа не знает ничего из этого, пока вы не воссоздадите это: продукты, цены, устаревшие тарифы, закреплённые только за существующими клиентами, поведение пробных периодов, купоны, правила с включённым налогом и якоря продления. Пропустите унаследованную цену — и лояльному клиенту выставят новый тариф: катастрофа для поддержки, которая ещё и проведёт выручку, которую потом придётся сторнировать.
3. Годовые планы создают перенос отложенной выручки. Клиент, купивший годовой план за 1200 долларов в марте, заплатил старому провайдеру, но вы зарабатываете эту выручку месяц за месяцем до следующего февраля. На дату переключения часть этих денег ещё не заработана, и она остаётся на вашем балансе как отложенная выручка, независимо от того, какая платформа обслуживает оставшиеся месяцы. Отчёты новой платформы никогда не покажут это обязательство — она знает только о продажах через неё, — поэтому миграция должна явно перенести остаток вперёд, иначе выручка второй половины года будет завышена на деньги, которые вы уже собрали.
4. Возвраты и чарджбэки пересекают точку переключения. Возврат, выданный в августе за продажу в мае, живёт в системе старого провайдера по старым правилам комиссий, тогда как выручка, которую он сторнирует, возможно, уже была признана в двух кварталах. Каждый провайдер берёт на себя чарджбэки как merchant of record, но бухгалтерские проводки — сторнирование выручки, фиксация любой невозвратной комиссии, корректировка уже полученной выплаты — попадают в ваши книги, и отчёты о корректировках каждого провайдера оформляют их по-разному.
5. График выплат, валюта и налоговая документация меняются одновременно. Графики выплат различаются у провайдеров, поэтому продажи одной недели могут попасть в банковские выписки разных месяцев до и после переключения. Продавцы, работающие через границы, сталкиваются с новыми строками курсовых разниц и новыми расшифровками комиссий. И каждый провайдер отчитывается о своих налоговых декларациях по своим регистрациям, тогда как продавцы из США могут получить отдельные отчёты о выплатах от каждой платформы за год. Ничто из этого не является ошибкой; это две корректные системы, расходящиеся в формате, и ваше закрытие должно нормализовать всё это в один план счетов.
Безопасный для финансов план миграции
Пройдите через эти шаги по порядку и не сокращайте параллельный запуск.
1. Установите дату переключения на границе периода. Переключения в середине месяца разрывают периоды подписок, пропорциональные начисления и пакеты выплат по шву. Переключение на конец месяца или квартала даёт вам чистые совокупности «до и после» и одно закрытие, которое содержит весь переход.
2. Заморозьте и экспортируйте всё со старой платформы. Закройте учётные периоды, по которым старый провайдер уже выставил счета. Экспортируйте полный каталог тарифов, каждую активную подписку с её ценой и датой продления, полную историю счетов-фактур и каждый отчёт о выплатах с расшифровками комиссий. Держите старый аккаунт в режиме только для чтения, а не удалённым, как минимум на протяжении полного аудиторского цикла — аудиторы и налоговые органы спрашивают именно о годе миграции, потому что ожидают этот шов.
3. Воссоздайте каталог тарифов, включая тарифы, которые вы больше не продаёте. Устаревшие и унаследованные тарифы должны существовать в новой системе до того, как первый мигрировавший клиент продлит там подписку. Задокументируйте каждое соответствие старого идентификатора тарифа новому; эта таблица соответствий — аудиторский след, объясняющий, почему июльские счета-фактуры выглядят иначе, чем июньские, для одного и того же клиента.
4. Сначала переведите новых клиентов на новую платформу. Запустите нового провайдера параллельно для новых продаж, пока существующие подписки доходят до продления на старом, затем переводите когорты на естественных границах — датах продления, концах месяца, никогда посреди цикла. Каждая когорта проходит свою сверку, прежде чем начнётся следующая. Единовременное переключение концентрирует каждую неудачу переподписки, каждый пропуск унаследованного тарифа и каждый краевой случай пропорционального начисления в одном закрытии.
5. Сопоставьте отчёты о выплатах обоих провайдеров с одним планом счетов. До первого закрытия, включающего обоих провайдеров, постройте трансляцию: каждая строка комиссии, налоговая строка, корректировка и код возврата в каждом отчёте сопоставляются с одним из ваших счетов регистра. Два провайдера никогда не используют одинаковые обозначения. Без этой таблицы соответствий ваш бухгалтер будет изобретать её по-разному каждый месяц.
6. Явно выверяйте отложенную выручку. Сверьте неработающий остаток план за планом на дату переключения и проведите любую разницу между записями старой платформы и вашим регистром как явную корректировку с задокументированной причиной — а не как подгонку. С момента переключения признавайте оставшийся остаток по графику, независимо от того, какая платформа обслуживает клиента.
Как месяц переключения выглядит в вашем регистре
Связь с бухгалтерией становится простой, как только вы разделите двух провайдеров с отдельным учётом комиссий, вместо того чтобы позволять обоим проводить напрямую в выручку. Признавайте каждую выплату в брутто — полный платёж клиента как выручку, долю провайдера как расход на продажу — и продолжайте признавать остатки отложенной выручки до переключения по их первоначальному графику. Документация Beancount описывает синтаксис регистра, использованный ниже, если что-то из этого незнакомо.
Предположим, клиент купил годовой план за 1200 долларов через Lemon Squeezy в середине марта. Мартовская выплата пришла за вычетом комиссии 5 процентов плюс 50 центов (60,50 доллара), и к 30 июня вы признали четыре месяца выручки (400 долларов), оставив 800 долларов незаработанными. 1 июля — ваша дата переключения, а в июле через Paddle продаётся новая месячная подписка за 49 долларов. В текстовом регистре это выглядит так:
2026-01-01 open Income:SaaS:Subscriptions
2026-01-01 open Liabilities:Deferred-Revenue
2026-01-01 open Expenses:MoR-Fees:LemonSqueezy
2026-01-01 open Expenses:MoR-Fees:Paddle
2026-01-01 open Assets:Checking
2026-03-15 * "Annual plan sale via Lemon Squeezy, buyer paid 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Recognize June portion of annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Monthly plan sale via Paddle, buyer paid 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Recognize July portion of pre-cutover annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USDТри детали несут всю миграцию. Во-первых, комиссии каждого провайдера проводятся на его собственный субсчёт, так что итоги на конец года точно показывают, во что вам обошлась каждая платформа, и две тарифные сетки комиссий никогда не смешиваются. Во-вторых, июльская проводка признания по мартовской продаже не меняется из-за переключения — отложенная выручка является вашим обязательством, зарабатываемым по вашему графику, и ей безразлично, какая платформа собрала деньги. В-третьих, каждая проводка привязана к конкретному отчёту о выплатах: уведомление о переводе Lemon Squeezy за март для первой, выплата Paddle за июль для третьей. Когда ваш бухгалтер спросит, как была заработана выручка за год, каждое число укажет ровно на документы одного провайдера.
Закройте шов осознанно
Миграция merchant of record — это два проекта под одним именем: перенос биллинга, который ваши инженеры завершают за недели, и перенос отчётности, с которым ваш бухгалтер живёт год. Проект биллинга заканчивается, когда последний клиент переподписывается. Проект отчётности заканчивается, когда каждая выплата от обоих провайдеров сверена с банком, каждая строка комиссии сопоставлена с одним планом счетов, остаток отложенной выручки чисто переходит через дату переключения, а записка «брутто против нетто» в вашем аудиторском файле покрывает обе половины года под одной политикой. Назначайте переключение на границе периода, запускайте новые продажи на новой платформе, пока старые подписки доходят до продления, и держите старую систему читаемой, пока аудиторы не увидят год миграции. Сделайте это — и переключение станет сноской в отчётности следующего года, а не отклонением, которое никто не может объяснить.
