Януарските ви плащания идват от 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, и двамата истински merchants of record при същата обявена ставка от 5 процента плюс 50 цента. Ако сте един от тях, смяната на билинг системата е лесната част. Поддържането на достоверни книги през нея е истинският проект.
Какво всъщност представлява merchant of record във вашите книги
Merchant of record е законният продавач на вашия продукт, а не просто вашият платежен процесор. Когато клиент купува чрез Paddle, Polar или Lemon Squeezy, извлечението по картата показва името на доставчика, данъчната фактура се издава от едно от собствените юридически лица на доставчика, а регистрациите за данък върху продажбите и ДДС в Германия, Япония или Тексас принадлежат на доставчика, а не на вас. Доставчикът изчислява, събира, декларира и внася данъка, поема отговорността за chargeback и ви изпраща плащане за остатъка.
Тази правна структура определя как изглеждат счетоводните ви записи. Фактурата към купувача документира продажбата на доставчика към вашия клиент — това е неговата фактура, не вашата. Вашата страна на сделката се документира с документи от страна на продавача: обратна фактура, описваща вашата доставка към доставчика, и известие за плащане, записващо сумата на всяко плащане. Вашият приход е плащане, нетно след таксата на доставчика, пристигащо по графика на доставчика, а не непрекъснато. Версията на тези документи на всеки доставчик изглежда различно — точно затова пускането на два от тях в една година разделя записите ви на две.
Решението бруто-срещу-нето, което трябва да вземете веднъж
Преди да пипнете която и да е от платформите, уредете единствената счетоводна политика, която миграцията ви принуждава да защитите: признавате ли пълната сума, платена от клиента, като приход (бруто), или само плащането, което сте получили (нето)?
Съгласно ASC 606 това е въпросът принципал срещу агент и се решава от контрола — не от това кой е издал фактурата или чието име е в извлечението по картата. Указанието се намира в ASC 606-10-55-36 до 55-40: предприятието е принципал, ако контролира конкретната стока или услуга, преди да я прехвърли на клиента, и отчита приходите бруто; ако обещанието му е само да организира друга страна да я предостави, предприятието е агент и отчита само своята такса или комисиона нето. За софтуерен доставчик, който продава чрез merchant of record от реселърски тип, същият анализ решава кой е вашият клиент. Ако вашият клиент е крайният потребител, приходът е цената за крайния потребител, а делът на доставчика е разход за продажба под линията на приходите. Ако вашият клиент е самият доставчик, приходът е цената, която доставчикът ви е платил — плащането.
Брутната печалба е идентична и в двата случая. Отчетеният приход не е, и това число захранва темпа ви на растеж, вашите мултипликатори на приходи при набиране на финансиране или придобиване, и всяко сравнение период-спрямо-период, което четете пред борда си. Повечето софтуерни доставчици, продаващи чрез маркетплейси и реселъри, стигат до бруто третиране, но всеки от двата отговора е защитим, ако анализът ви го подкрепя. Това, което не е защитимо, е отклоняването: отчитане на плащанията от Lemon Squeezy нето през първата половина на годината и на плащанията от Paddle бруто през втората, защото отчетите на новия доставчик направиха бруто по-лесно. Изберете една политика, запишете анализа на контрола в бележка, която одиторът ви може да прочете, и я прилагайте идентично към плащанията на двамата доставчици за цялата година.
Петте шева, по които годината се разделя на две
1. Абонаментите не се мигрират; клиентите се абонират наново. Няма автоматична миграция на токени между платежните процесори. Запазените карти обикновено не могат да бъдат експортирани от merchant of record в използваема форма, така че планирайте абонатите да въведат отново платежни данни на новата платформа — или потвърдете писмено, преди да се ангажирате, че новият доставчик може да премести активните абонаменти и запазените карти вместо вас. Докато всеки клиент се абонира наново, старата платформа продължава да таксува — което означава, че двете системи работят едновременно месеци наред и всяко месечно приключване съгласува два потока от плащания.
2. Запазените цени и котвите за подновяване трябва да се пресъздадат ръчно. Всеки активен абонамент носи цена, дата на подновяване и често запазен план, който вече не се продава. Новата платформа не знае нищо от това, докато не го пресъздадете: продукти, цени, наследени планове, държани само от съществуващи клиенти, поведение при пробен период, купони, правила за цени с включен данък и котви за подновяване. Пропуснете запазена цена и лоялен клиент бива таксуван по новата ставка — поддръжкова катастрофа, която също осчетоводява приходи, които после трябва да сторнирате.
3. Годишните планове създават преминаване на отложени приходи. Клиент, купил годишен план за $1,200 през март, е платил на стария доставчик, но вие печелите този приход месец по месец до следващия февруари. Към датата на преминаване част от този паричен поток все още е неспечелена и остава в баланса ви като отложен приход, независимо коя платформа обслужва оставащите месеци. Отчетите на новата платформа никога няма да покажат това задължение — тя знае само за продажби, направени чрез нея — така че миграцията трябва изрично да пренесе баланса, иначе приходите ви през втората половина са надценени с пари, които вече сте събрали.
4. Възстановяванията и chargeback-овете пресичат датата на преминаване. Възстановяване, издадено през август за продажба от май, живее в системата на стария доставчик, по старите правила за такси, докато приходът, който сторнира, може вече да е признат през две тримесечия. Всеки доставчик поема chargeback-овете като 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 са два проекта под едно име: преместването на билинг системата, което инженерите ви завършват за седмици, и преместването на книгите, с които счетоводителят ви живее цяла година. Проектът по билинг системата приключва, когато последният клиент се абонира наново. Проектът по книгите приключва, когато всяко плащане от двамата доставчици се връзва с банката, всеки ред за такса се съпоставя с един сметкоплан, балансът на отложените приходи преминава чисто през датата на преминаване и бележката за бруто-срещу-нето в одиторското ви досие покрива двете половини на годината по една политика. Насрочете преминаването на граница на период, пускайте новите продажби на новата платформа, докато старите абонаменти стигат до подновяване, и дръжте старата система четлива, докато одиторите видят годината на миграция. Направете това и смяната ще бъде бележка под линия във финансовите отчети за следващата година, вместо отклонението, което никой не може да обясни.
