Ваші січневі виплати надходили від 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. Річні плани створюють перехід відкладеного доходу. Клієнт, який купив річний план за $1 200 у березні, сплатив старому провайдеру, але ви заробляєте цей дохід місяць за місяцем до наступного лютого. На дату переходу частина цих грошей ще не зароблена, і вона залишається на вашому балансі як відкладений дохід, незалежно від того, яка платформа обслуговує решту місяців. Звіти нової платформи ніколи не покажуть цього зобов'язання — вона знає лише про продажі, здійснені через неї — тож міграція має явно перенести залишок уперед, інакше ваш дохід другої половини року буде завищений на суму, яку ви вже зібрали.
4. Повернення коштів і чарджбеки перетинають межу переходу. Повернення, видане в серпні за продажем, здійсненим у травні, живе в системі старого провайдера за старими правилами комісій, тоді як дохід, який воно сторнує, міг уже бути визнаний протягом двох кварталів. Кожен провайдер бере на себе чарджбеки як merchant of record, але бухгалтерські проводки — сторнування доходу, відображення будь-якої неповоротної комісії, коригування вже отриманої виплати — потрапляють у ваші книги, і звіти про коригування кожного провайдера форматують їх по-різному.
5. Час виплат, валюта й податкова документація змінюються одночасно. Графіки виплат відрізняються залежно від провайдера, тож продажі одного тижня можуть потрапити до банківських виписок різних місяців до і після перемикання. Продавці, що працюють через кордон, стикаються з новими рядками валютних курсів та новими розшифровками комісій. І кожен провайдер подає власні податкові декларації за власними реєстраціями, тоді як американські продавці можуть отримувати окрему звітність про виплати від кожної платформи за рік. Ніщо з цього не є помилкою; це дві правильні системи, що розходяться у форматі, і ваше закриття має нормалізувати все це до одного плану рахунків.
Безпечна для фінансів методика міграції
Просувайтеся цими кроками по черзі й не скорочуйте паралельний період.
1. Встановіть дату переходу на межі періоду. Переходи посеред місяця розщеплюють періоди підписок, пропорційні нарахування та партії виплат через шов. Перехід на кінець місяця чи кварталу дає вам чисті сукупності до й після та одне закриття, що містить увесь перехід.
2. Заморозьте й експортуйте все зі старої платформи. Замкніть облікові періоди, які старий провайдер уже виставив рахунками. Експортуйте повний каталог планів, кожну активну підписку з її ціною та датою поновлення, повну історію рахунків-фактур і кожен звіт про виплати з розшифровками комісій. Тримайте старий обліковий запис доступним лише для читання, не видаленим, щонайменше протягом повного аудиторського циклу — аудитори й податкові органи запитують саме про рік міграції, бо очікують на цей шов.
3. Відтворіть каталог планів, включно з планами, які ви більше не продаєте. Застарілі та ґрандфазерні плани мають існувати в новій системі до того, як перший мігрований клієнт поновить підписку там. Задокументуйте кожне зіставлення старого ідентифікатора плану з новим; ця таблиця зіставлення є аудиторським слідом, що пояснює, чому липневі рахунки-фактури для того самого клієнта виглядають інакше, ніж червневі.
4. Спершу переведіть нових клієнтів на нову платформу. Запустіть нового провайдера паралельно для нових продажів, поки наявні підписки доходять до поновлення на старому, потім переводьте когорти на природних межах — датах поновлення, кінцях місяців, ніколи посеред циклу. Кожна когорта отримує власне звіряння, перш ніж почнеться наступна. Перехід «усе одразу» концентрує кожен збій повторної підписки, кожен пропуск ґрандфазерингу та кожен крайній випадок пропорційного нарахування в одне закриття.
5. Зіставте обидва звіти про виплати з одним планом рахунків. Перш ніж перше закриття включатиме обох провайдерів, побудуйте трансляцію: кожен рядок комісії, рядок податку, коригування й код повернення в кожному звіті зіставляється з одним із ваших рахунків регістру. Два провайдери ніколи не використовуватимуть однакові позначки. Без зіставлення ваш бухгалтер вигадуватиме його по-новому щомісяця.
6. Вирівняйте відкладений дохід явно. Звірте незароблений залишок план за планом на дату переходу й проведіть будь-яку різницю між записами старої платформи та вашим регістром як явне коригування з задокументованою причиною — а не як балансувальну підстановку. Від переходу й надалі визнавайте залишок за графіком, незалежно від того, яка платформа обслуговує клієнта.
Як місяць переходу виглядає у вашому регістрі
Бухгалтерський зв'язок стає простим, щойно ви розділите двох провайдерів окремим відстеженням комісій, замість того щоб дозволяти обом проводити кошти одразу на дохід. Визнавайте кожну виплату у валовій сумі — повний платіж клієнта як дохід, частку провайдера як витрати на продаж — і продовжуйте визнавати залишки відкладеного доходу до переходу за їхнім початковим графіком. Документація Beancount описує синтаксис регістру, використаний нижче, якщо щось із нього незнайоме.
Припустімо, клієнт купив річний план за $1 200 через Lemon Squeezy в середині березня. Березнева виплата надійшла за вирахуванням комісії 5 відсотків плюс 50 центів ($60,50), і станом на 30 червня ви визнали чотири місяці доходу ($400), залишивши $800 незаробленими. 1 липня — ваша дата переходу, і нова щомісячна підписка за $49 продається через Paddle у липні. У текстовому регістрі це виглядає так:
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 — це два проєкти під однією назвою: переміщення білінгу, яке ваші інженери завершують за тижні, і переміщення книг, з яким ваш бухгалтер живе протягом року. Проєкт білінгу завершується, коли останній клієнт оформлює підписку заново. Проєкт книг завершується, коли кожна виплата від обох провайдерів звіряється з банком, кожен рядок комісії зіставляється з одним планом рахунків, залишок відкладеного доходу чисто проходить через дату переходу, а меморандум про валовий проти чистого обліку у вашому аудиторському файлі охоплює обидві половини року за однією політикою. Заплануйте перехід на межі періоду, запустіть нові продажі на новій платформі, поки старі підписки доходять до поновлення, і тримайте стару систему читабельною, доки аудитори не побачать рік міграції. Зробіть це — і перемикання стане виноскою у фінансовій звітності наступного року, а не відхиленням, яке ніхто не може пояснити.
