Vaše januárové výplaty prišli z Lemon Squeezy a vaše augustové výplaty prichádzajú z Paddle a teraz sa váš účtovník pýta otázku, na ktorú ani jeden dashboard nedokáže odpovedať sám: koľko výnosov z predplatného ste tento rok skutočne zarobili? Starý poskytovateľ vyberal podľa jedného sadzobníka poplatkov, jedného rytmu výplat a jedného súboru daňových faktúr vystavených jeho vlastnými entitami. Nový poskytovateľ robí tú istú prácu s inými reportmi, inými riadkami poplatkov a inou dokumentáciou. Medzi nimi leží zostatok odložených výnosov, kopa ročných plánov predaných na jednej platforme a obsluhovaných na inej a závierka roka, ktorá musí spojiť dve nezlučiteľné účtovné knihy do jedného uveriteľného súboru kníh. Práve toto spájanie — nie integrácia API, ktorá trvá dni — je miesto, kde migrácie merchant-of-record potichu zlyhávajú.
Toto je aktuálne rozhodnutie pre tisíce predajcov. Stripe získal Lemon Squeezy v júli 2024 a januárová aktualizácia Lemon Squeezy z roku 2026 uviedla, že jeho budúcnosťou je jednoduchá migračná cesta na Stripe Managed Payments, vlastný produkt Stripe pre merchant-of-record. Žiadny termín nebol zverejnený a Lemon Squeezy stále funguje, ale predajcovia, ktorí nechcú byť migrovaní podľa niekoho iného časového plánu, zvažujú nezávislých poskytovateľov: Paddle a Polar, obaja skutoční merchant-of-record s rovnakou základnou sadzbou 5 percent plus 50 centov. Ak ste jedným z nich, prepnutie fakturácie je tá jednoduchá časť. Udržať účtovné knihy uveriteľné počas neho je ten skutočný projekt.
Čo je merchant of record vo vašich knihách
Merchant of record je zákonný predajca vášho produktu, nielen váš spracovateľ platieb. Keď zákazník nakupuje cez Paddle, Polar alebo Lemon Squeezy, výpis z karty uvádza poskytovateľa, daňová faktúra je vystavená jednou z entít samotného poskytovateľa a registrácie dane z predaja a DPH v Nemecku, Japonsku alebo Texase patria poskytovateľovi, nie vám. Poskytovateľ vypočíta, vyberie, podá a odvedie daň, absorbuje zodpovednosť za chargebacky a pošle vám výplatu za zvyšok.
Táto právna štruktúra rozhoduje o tom, ako vyzerajú vaše účtovné záznamy. Faktúra kupujúceho dokumentuje predaj poskytovateľa vášmu zákazníkovi — je to jeho faktúra, nie vaša. Vaša strana transakcie je zdokumentovaná záznamami na strane predávajúceho: reverzná faktúra opisujúca váš dodávku poskytovateľovi a výplatné avízo zaznamenávajúce každú sumu výplaty. Váš výnos je výplata, čistá po odpočítaní poplatku poskytovateľa, prichádzajúca podľa harmonogramu poskytovateľa, nie priebežne. Verzia týchto dokumentov sa u každého poskytovateľa líši, a práve preto prevádzkovanie dvoch z nich v jednom roku rozdelí vaše záznamy na dve časti.
Rozhodnutie hrubý verzus čistý, ktoré musíte urobiť raz
Skôr než sa dotknete ktorejkoľvek platformy, vyriešte jednu účtovnú politiku, ktorú vás migrácia núti obhájiť: uznávate ako výnos celú sumu, ktorú zákazník zaplatil (hrubý), alebo iba výplatu, ktorú ste dostali (čistý)?
Podľa ASC 606 ide o otázku principal verzus agent a odpovedá sa na ňu kontrolou — nie tým, kto vystavil faktúru alebo koho meno je na výpise z karty. Usmernenie sa nachádza v ASC 606-10-55-36 až 55-40: entita je principal, ak kontroluje špecifikovaný tovar alebo službu predtým, než ich prevedie na zákazníka, a vykazuje výnosy hrubé; ak jej prísľubom je iba zabezpečiť, aby ich poskytla iná strana, entita je agent a vykazuje iba svoj poplatok alebo províziu čisté. Pre softvérového dodávateľa predávajúceho cez merchant-of-record v štýle prepredajcu rovnaká analýza rozhoduje o tom, kto je váš zákazník. Ak je vaším zákazníkom koncový používateľ, výnosom je cena pre koncového používateľa a podiel poskytovateľa je predajný náklad pod líniou výnosov. Ak je vaším zákazníkom samotný poskytovateľ, výnosom je cena, ktorú vám poskytovateľ zaplatil — výplata.
Hrubý zisk je v oboch prípadoch rovnaký. Vykázaný výnos nie je, a toto číslo ovplyvňuje vašu mieru rastu, vaše násobky výnosov pri získavaní kapitálu alebo akvizícii a každé medziobdobové porovnanie, ktoré číta vaša rada. Väčšina softvérových dodávateľov predávajúcich cez trhoviská a prepredajcov sa prikloní k hrubému vykazovaniu, ale obe odpovede sú obhájiteľné, ak ich podporuje vaša analýza. Neobhájiteľné je kolísanie: účtovanie výplat Lemon Squeezy čisté v prvej polovici roka a výplat Paddle hrubé v druhej polovici, pretože reporty nového poskytovateľa urobili hrubé vykazovanie jednoduchším. Zvoľte jednu politiku, zapíšte analýzu kontroly do memoranda, ktoré váš audítor dokáže prečítať, a aplikujte ju identicky na výplaty oboch poskytovateľov po celý rok.
Päť švov, kde sa rok rozdelí na dva
1. Predplatné sa nemigruje; zákazníci sa znova prihlásia na odber. Medzi spracovateľmi platieb neexistuje automatická migrácia tokenov. Uložené karty sa vo všeobecnosti nedajú z merchant-of-record exportovať v použiteľnej podobe, takže počítajte s tým, že odberatelia znova zadajú platobné údaje na novej platforme — alebo si pred záväzkom písomne potvrďte, že nový poskytovateľ dokáže za vás presunúť aktívne predplatné a uložené karty. Kým sa každý zákazník znova neprihlási na odber, stará platforma mu naďalej účtuje, čo znamená, že oba systémy bežia súbežne mesiace a každá mesačná závierka zosúlaďuje dva toky výplat.
2. Zachované ceny a kotvy obnovenia treba prestavať ručne. Každé aktívne predplatné nesie cenu, dátum obnovenia a často zachovaný plán, ktorý sa už nepredáva. Nová platforma o tom nič nevie, kým to nevytvoríte: produkty, ceny, staršie plány, ktoré vlastnia iba existujúci zákazníci, správanie skúšobných období, kupóny, pravidlá cien vrátane dane a kotvy obnovenia. Ak vynecháte zachovanú cenu, vernému zákazníkovi sa naúčtuje nová sadzba — katastrofa pre podporu, ktorá navyše zaúčtuje výnos, ktorý potom musíte stornovať.
3. Ročné plány vytvárajú prechod odložených výnosov. Zákazník, ktorý si v marci kúpil ročný plán za 1 200 USD, zaplatil starému poskytovateľovi, ale vy tento výnos zarábate mesiac po mesiaci až do nasledujúceho februára. K dátumu prechodu je časť tejto hotovosti stále nezaslúžená a zostáva vo vašej súvahe ako odložený výnos bez ohľadu na to, ktorá platforma obsluhuje zostávajúce mesiace. Reporty novej platformy túto záväzok nikdy neukážu — vie iba o predajoch uskutočnených cez ňu — takže migrácia musí zostatok explicitne preniesť, inak sú vaše výnosy v druhej polovici nadhodnotené o peniaze, ktoré ste už vybrali.
4. Vratky a chargebacky prekračujú prechod. Vratka vystavená v auguste za predaj z mája žije v systéme starého poskytovateľa pod starými pravidlami poplatkov, zatiaľ čo výnos, ktorý ruší, mohol byť už uznaný naprieč dvoma štvrťrokmi. Každý poskytovateľ absorbuje chargebacky ako merchant of record, ale účtovné zápisy — rušenie výnosu, zaznamenanie akéhokoľvek nevratného poplatku, úprava výplaty, ktorú ste už dostali — padajú do vašich kníh a reporty úprav každého poskytovateľa ich formátujú inak.
5. Načasovanie výplat, mena a daňová dokumentácia sa menia naraz. Harmonogramy výplat sa líšia podľa poskytovateľa, takže predaj z toho istého týždňa môže pred a po prepnutí prísť na bankové výpisy rôznych mesiacov. Cezhraniční predajcovia čelia novým riadkom devízových rozdielov a novým rozpisom poplatkov. A každý poskytovateľ vykazuje svoje vlastné daňové priznania pod svojimi vlastnými registráciami, pričom predajcovia v USA môžu za daný rok dostať od každej platformy samostatné výkazy výplat. Nič z toho nie sú chyby; sú to dva správne systémy, ktoré sa nezhodujú vo formáte, a vaša závierka musí všetky z nich normalizovať na jednu účtovú osnovu.
Finančne bezpečný scenár migrácie
Prejdite týmto v poradí a paralelný beh neskracujte.
1. Nastavte dátum prechodu na hranici obdobia. Prechody v polovici mesiaca rozdeľujú obdobia predplatného, pomerné sumy a dávky výplat naprieč švom. Prechod na konci mesiaca alebo štvrťroka vám dá čisté populácie pred a po a jednu závierku, ktorá obsahuje celý prechod.
2. Zmrazte a exportujte všetko zo starej platformy. Zamknite účtovné obdobia, ktoré starý poskytovateľ už vyfakturoval. Exportujte celý katalóg plánov, každé aktívne predplatné s jeho cenou a dátumom obnovenia, kompletnú históriu faktúr a každý report výplat s rozpisom poplatkov. Starý účet ponechajte iba na čítanie, nie zmazaný, aspoň počas celého audítorského cyklu — audítori a daňové orgány sa pýtajú konkrétne na rok migrácie, pretože ten šev očakávajú.
3. Znovu vytvorte katalóg plánov vrátane plánov, ktoré už nepredávate. Staršie a zachované plány musia existovať v novom systéme skôr, než sa tam prvý migrovaný zákazník obnoví. Zdokumentujte každé mapovanie zo starého ID plánu na nové; táto mapovacia tabuľka je audítorská stopa, ktorá vysvetľuje, prečo júlové faktúry vyzerajú inak ako júnové faktúry pre toho istého zákazníka.
4. Nových zákazníkov dajte najprv na novú platformu. Prevádzkujte nového poskytovateľa paralelne pre nové predaje, zatiaľ čo existujúce predplatné idú k obnoveniu na starom, potom presúvajte kohorty na prirodzených hraniciach — dátumy obnovenia, konce mesiacov, nikdy v polovici cyklu. Každá kohorta dostane vlastné zosúladenie predtým, než sa začne ďalšia. Prechod veľkým treskom koncentruje každé zlyhanie opätovného prihlásenia na odber, každé vynechanie zachovanej ceny a každý hraničný prípad pomerných súm do jednej závierky.
5. Namapujte oba reporty výplat na jednu účtovú osnovu. Pred prvou závierkou, ktorá obsahuje oboch poskytovateľov, vytvorte preklad: každý riadok poplatku, daňový riadok, úprava a kód vratky na každom reporte sa mapuje na jeden z vašich účtovných účtov. Obaja poskytovatelia nikdy nebudú používať rovnaké označenia. Bez mapovania si ho váš účtovník každý mesiac vymyslí inak.
6. Zosúlaďte odložené výnosy explicitne. Zosúlaďte nezaslúžený zostatok plán po pláne k dátumu prechodu a akýkoľvek rozdiel medzi záznamami starej platformy a vašou účtovnou knihou zaúčtujte ako explicitnú úpravu s zdokumentovanou príčinou — nie ako vyrovnávaciu položku. Od prechodu ďalej uznávajte zostávajúci zostatok podľa harmonogramu bez ohľadu na to, ktorá platforma zákazníka obsluhuje.
Ako vyzerá mesiac prechodu vo vašej účtovnej knihe
Prepojenie s účtovníctvom je priamočiare, keď oboch poskytovateľov oddelíte pomocou samostatného sledovania poplatkov namiesto toho, aby obaja zaúčtovávali priamo do výnosov. Uznávajte každú výplatu hrubú — celú platbu zákazníka ako výnos, podiel poskytovateľa ako predajný náklad — a naďalej uznávajte odložené zostatky spred prechodu podľa ich pôvodného harmonogramu. Dokumentácia Beancount pokrýva syntax účtovnej knihy použitú nižšie, ak je vám niečo z toho neznáme.
Predpokladajme, že zákazník si v polovici marca kúpil ročný plán za 1 200 USD cez Lemon Squeezy. Marcová výplata prišla čistá po odpočítaní poplatku 5 percent plus 50 centov (60,50 USD) a do 30. júna ste uznali štyri mesiace výnosov (400 USD), čím zostáva 800 USD nezaslúžených. 1. júl je váš dátum prechodu a nové mesačné predplatné za 49 USD sa v júli predáva cez Paddle. V účtovnej knihe v čistom texte to vyzerá takto:
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 USDCelú migráciu nesú tri detaily. Po prvé, poplatky každého poskytovateľa sa zaúčtujú na jeho vlastný podúčet, takže ročné súčty presne ukazujú, čo vás každá platforma stála, a dva sadzobníky poplatkov sa nikdy nemiešajú. Po druhé, júlový zápis o uznaní za marcový predaj prechod nemení — odložený výnos je váš záväzok, zaslúžený podľa vášho harmonogramu, a nezaujíma ho, ktorá platforma vybrala hotovosť. Po tretie, každý zápis sa spája s konkrétnym reportom výplat: výplatné avízo Lemon Squeezy z marca pre prvý, výplata Paddle z júla pre tretí. Keď sa váš účtovník pýta, ako sa výnos roka zarobil, každé číslo ukazuje na dokumentáciu presne jedného poskytovateľa.
Zatvorte šev zámerne
Migrácia merchant-of-record sú dva projekty pod jedným názvom: presun fakturácie, ktorý vaši inžinieri dokončia za týždne, a presun kníh, s ktorými váš účtovník žije rok. Projekt fakturácie sa končí, keď sa posledný zákazník znova prihlási na odber. Projekt kníh sa končí, keď sa každá výplata od oboch poskytovateľov spája s bankou, každý riadok poplatku sa mapuje na jednu účtovú osnovu, zostatok odložených výnosov čisto prekročí dátum prechodu a memorandum o hrubom verzus čistom vo vašom audítorskom spise pokrýva obe polovice roka pod jednou politikou. Naplánujte prechod na hranici obdobia, spúšťajte nové predaje na novej platforme, zatiaľ čo staré predplatné idú k obnoveniu, a starý systém ponechajte čitateľný, kým audítori neuvidia rok migrácie. Urobte to a prepnutie bude poznámkou pod čiarou v budúcoročnej účtovnej závierke namiesto odchýlky, ktorú nikto nedokáže vysvetliť.
