Salta al contingut principal

Migrar de Lemon Squeezy a Polar o Paddle després de l'adquisició per Stripe? Per què canviar de proveïdor de merchant-of-record a mig any divideix el teu reconeixement d'ingressos en dos llibres incompatibles

Publicat 13 minuts de lecturaMike ThriftMike Thrift
Migrar de Lemon Squeezy a Polar o Paddle després de l'adquisició per Stripe? Per què canviar de proveïdor de merchant-of-record a mig any divideix el teu reconeixement d'ingressos en dos llibres incompatibles
En aquesta pàgina

Els teus pagaments de gener van venir de Lemon Squeezy i els d'agost venen de Paddle, i ara el teu comptable fa una pregunta que cap dels dos panells pot respondre per si sol: quants ingressos per subscripció vas guanyar realment aquest any? El proveïdor antic cobrava sota un esquema de comissions, una cadència de pagaments i un conjunt de factures fiscals emeses des de les seves pròpies entitats. El nou proveïdor fa la mateixa feina amb informes diferents, línies de comissions diferents i documentació diferent. Entre tots dos hi ha un saldo d'ingressos diferits, una pila de plans anuals venuts en una plataforma i atesos en una altra, i un tancament de final d'any que ha de cosir dos llibres incompatibles en un conjunt de comptes creïble. Aquesta costura — no la integració de l'API, que es fa en dies — és on les migracions de merchant-of-record fallen silenciosament.

Aquesta és una decisió viva per a milers de venedors ara mateix. Stripe va adquirir Lemon Squeezy el juliol de 2024, i l'actualització de gener de 2026 de Lemon Squeezy deia que el seu futur és un camí de migració fàcil cap a Stripe Managed Payments, el producte de merchant-of-record del mateix Stripe. No s'ha publicat cap data límit i Lemon Squeezy encara funciona, però els venedors que no volen ser migrats segons el calendari d'un altre estan avaluant els independents: Paddle i Polar, tots dos autèntics merchants of record amb la mateixa tarifa de referència del 5 per cent més 50 cèntims. Si ets un d'ells, el canvi de facturació és la part fàcil. Mantenir els llibres creïbles a través del canvi és el projecte real.

Què és realment un merchant of record als teus llibres​

Un merchant of record és el venedor legal del teu producte, no només el teu processador de pagaments. Quan un client compra a través de Paddle, Polar o Lemon Squeezy, l'extracte de la targeta indica el proveïdor, la factura fiscal s'emet des d'una de les entitats pròpies del proveïdor, i els registres d'impost sobre vendes i IVA a Alemanya, el Japó o Texas pertanyen al proveïdor i no a tu. El proveïdor calcula, recapta, declara i remet l'impost, assumeix la responsabilitat dels contracàrrecs i t'envia un pagament per la resta.

Aquesta estructura legal decideix com són els teus registres comptables. La factura del comprador documenta la venda del proveïdor al teu client — és la seva factura, no la teva. El teu costat de la transacció es documenta amb registres del costat del venedor: una factura inversa que descriu el teu subministrament al proveïdor i un avís de remesa que registra cada import del pagament. Els teus ingressos són un pagament, net de la comissió del proveïdor, que arriba segons el calendari del proveïdor en lloc de contínuament. La versió de cada proveïdor d'aquests documents sembla diferent, que és exactament per què executar-ne dos en un any divideix els teus registres en dos.

La decisió brut-versus-net que has de prendre una vegada​

Abans de tocar qualsevol de les plataformes, resol la única política comptable que la migració t'obliga a defensar: reconeixes l'import total que el client va pagar com a ingressos (brut), o només el pagament que vas rebre (net)?

Sota l'ASC 606, aquesta és la qüestió de principal-versus-agent, i es respon pel control — no per qui va emetre la factura ni per què el nom apareix a l'extracte de la targeta. L'orientació es troba a l'ASC 606-10-55-36 fins al 55-40: una entitat és un principal si controla el bé o servei especificat abans de transferir-lo al client, i informa els ingressos en brut; si la seva promesa només és aconseguir que una altra part el proporcioni, l'entitat és un agent i informa només la seva comissió o comissió neta. Per a un venedor de programari que ven a través d'un merchant of record d'estil revenda, la mateixa anàlisi decideix qui és el teu client. Si el teu client és l'usuari final, els ingressos són el preu de l'usuari final i la part del proveïdor és un cost de venda per sota de la línia d'ingressos. Si el teu client és el proveïdor mateix, els ingressos són el preu que el proveïdor et va pagar — el pagament.

El benefici brut és idèntic en tots dos casos. Els ingressos reportats no ho són, i aquest número alimenta la teva taxa de creixement, els teus múltiples d'ingressos en una ronda de finançament o adquisició, i cada comparació període-a-període que llegeix el teu consell. La majoria de venedors de programari que venen a través de marketplaces i revendes acaben en el tractament brut, però qualsevol de les dues respostes és defensable si la teva anàlisi la recolza. El que no és defensable és anar a la deriva: registrar els pagaments de Lemon Squeezy en net a la primera meitat de l'any i els pagaments de Paddle en brut a la segona meitat perquè els informes del nou proveïdor van fer el brut més fàcil. Tria una política, escriu l'anàlisi de control en un memoràndum que el teu auditor pugui llegir, i aplica-la idènticament als pagaments de tots dos proveïdors durant tot l'any.

Les cinc costures on l'any es divideix en dos​

1. Les subscripcions no migren; els clients es tornen a subscriure. No hi ha migració automàtica de tokens entre processadors de pagaments. Les targetes desades generalment no es poden exportar d'un merchant of record en forma utilitzable, així que planifica que els subscriptors tornin a introduir les dades de pagament a la nova plataforma — o confirma per escrit, abans de comprometre't, que el nou proveïdor pot traslladar les subscripcions actives i les targetes desades per tu. Fins que cada client es torni a subscriure, la plataforma antiga els continua facturant, la qual cosa significa que els dos sistemes funcionen en paral·lel durant mesos i el tancament de cada mes reconcilia dos fluxos de pagaments.

2. Els preus heretats i les àncores de renovació s'han de reconstruir a mà. Cada subscripció activa comporta un preu, una data de renovació, i sovint un pla heretat que ja no es ven. La nova plataforma no en sap res fins que el recrees: productes, preus, plans antics que només tenen els clients existents, comportament de proves, cupons, regles d'impostos inclosos, i àncores de renovació. Si t'equivoques amb un preu heretat, un client lleial rep el càrrec a la tarifa nova — un desastre d'atenció al client que també registra ingressos que després has de revertir.

3. Els plans anuals creen un tall d'ingressos diferits. Un client que va comprar un pla anual de 1.200 $ al març va pagar al proveïdor antic, però tu guanyes aquests ingressos mes a mes fins al febrer següent. A la data del tall, part d'aquest efectiu encara no s'ha guanyat, i es queda al teu balanç com a ingressos diferits independentment de quina plataforma presti servei als mesos restants. Els informes de la nova plataforma mai mostraran aquest passiu — només sap de les vendes fetes a través seu — així que la migració ha de traslladar el saldo explícitament o els teus ingressos de la segona meitat quedaran sobrevalorats per diners que ja vas cobrar.

4. Els reemborsaments i contracàrrecs travessen el tall. Un reemborsament emès a l'agost per una venda feta al maig viu al sistema del proveïdor antic, sota les regles de comissions antigues, mentre que els ingressos que reverteix poden haver-se reconegut ja durant dos trimestres. Cada proveïdor absorbeix els contracàrrecs com a merchant of record, però els assentaments comptables — revertir ingressos, registrar qualsevol comissió no reemborsable, ajustar el pagament que ja vas rebre — aterren als teus llibres, i els informes d'ajustament de cada proveïdor els formategen de manera diferent.

5. El moment dels pagaments, la moneda i la documentació fiscal canvien alhora. Els calendaris de pagaments difereixen segons el proveïdor, així que les vendes de la mateixa setmana poden aterrar als extractes bancaris de mesos diferents abans i després del canvi. Els venedors transfronterers s'enfronten a noves línies de divises i nous desglossaments de comissions. I cada proveïdor informa de les seves pròpies declaracions fiscals sota els seus propis registres, mentre que els venedors dels EUA poden rebre informes de pagaments separats de cada plataforma per a l'any. Cap d'aquests són errors; són dos sistemes correctes que discrepen en format, i el teu tancament ha de normalitzar-los tots en un sol pla comptable.

El manual de migració segur per a les finances​

Treballa aquests punts en ordre, i no comprimeixis l'execució en paral·lel.

1. Fixa la data del tall en un límit de període. Els talls a mig mes divideixen els períodes de subscripció, la prorrata i els lots de pagaments a través de la costura. Un tall a final de mes o de trimestre et dona poblacions netes d'abans i després i un tancament que conté tota la transició.

2. Congela i exporta-ho tot de la plataforma antiga. Bloqueja els períodes comptables que el proveïdor antic ja ha facturat. Exporta el catàleg complet de plans, cada subscripció activa amb el seu preu i data de renovació, l'historial complet de factures, i cada informe de pagaments amb desglossaments de comissions. Mantén el compte antic de només lectura, no eliminat, durant almenys un cicle d'auditoria complet — els auditors i les autoritats fiscals pregunten específicament per l'any de la migració perquè esperen la costura.

3. Recrea el catàleg de plans, incloent-hi els plans que ja no vens. Els plans antics i heretats han d'existir al nou sistema abans que el primer client migrat es renovi allà. Documenta cada mapatge d'un ID de pla antic a un de nou; aquesta taula de mapatge és el rastre d'auditoria que explica per què les factures de juliol semblen diferents de les de juny per al mateix client.

4. Posa els clients nous a la nova plataforma primer. Executa el nou proveïdor en paral·lel per a les vendes noves mentre les subscripcions existents arriben a la renovació a l'antic, i després mou cohorts en límits naturals — dates de renovació, finals de mes, mai a mig cicle. Cada cohort té la seva pròpia conciliació abans que comenci la següent. Un tall de cop i volta concentra cada fallada de re-subscripció, cada error d'heretatge i cada cas límit de prorrata en un sol tancament.

5. Mapa els informes de pagaments de tots dos proveïdors en un sol pla comptable. Abans del primer tancament que inclogui tots dos proveïdors, construeix la traducció: cada línia de comissió, línia d'impostos, ajustament i codi de reemborsament de cada informe s'assigna a un dels teus comptes del llibre major. Els dos proveïdors mai faran servir les mateixes etiquetes. Sense el mapatge, el teu comptable l'inventa de manera diferent cada mes.

6. Ajusta els ingressos diferits explícitament. Reconcilia el saldo no guanyat pla per pla a la data del tall, i registra qualsevol diferència entre els registres de la plataforma antiga i el teu llibre major com un ajustament explícit amb una causa documentada — no com un pedaç. Des del tall endavant, reconeix el saldo restant segons el calendari independentment de quina plataforma atén el client.

Com es veu el mes del tall al teu llibre major​

La connexió comptable és senzilla un cop separes els dos proveïdors amb un seguiment de comissions diferent en lloc de deixar que tots dos registrin directament als ingressos. Reconeix cada pagament en brut — el pagament complet del client com a ingressos, la part del proveïdor com a despesa de venda — i continua reconeixent els saldos diferits d'abans del tall segons el seu calendari original. La documentació de Beancount cobreix la sintaxi del llibre major utilitzada a continuació si alguna part no et resulta familiar.

Suposa que un client va comprar un pla anual de 1.200 $ a través de Lemon Squeezy a mitjan març. El pagament de març va arribar net de la comissió del 5 per cent més 50 cèntims (60,50 $), i al 30 de juny has reconegut quatre mesos d'ingressos (400 $), deixant 800 $ no guanyats. L'1 de juliol és la teva data de tall, i una nova subscripció mensual de 49 $ es ven a través de Paddle al juliol. En un llibre major de text pla això sembla així:

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

Tres detalls sostenen tota la migració. Primer, les comissions de cada proveïdor es registren al seu propi subcompte, així que els totals de final d'any mostren exactament què et va costar cada plataforma i els dos esquemes de comissions mai es barregen. Segon, l'assentament de reconeixement de juliol per a la venda de març no canvia pel tall — els ingressos diferits són el teu passiu, guanyats segons el teu calendari, i no li importa quina plataforma va cobrar l'efectiu. Tercer, cada assentament lliga amb un informe de pagaments específic: l'avís de remesa de Lemon Squeezy de març per al primer, el pagament de Paddle de juliol per al tercer. Quan el teu comptable pregunti com es van guanyar els ingressos de l'any, cada número apunta exactament a la documentació d'un sol proveïdor.

Tanca la costura deliberadament​

Una migració de merchant-of-record són dos projectes amb un sol nom: moure la facturació, que els teus enginyers acaben en setmanes, i moure els llibres, amb què el teu comptable conviu durant un any. El projecte de facturació acaba quan l'últim client es torna a subscriure. El projecte dels llibres acaba quan cada pagament de tots dos proveïdors lliga amb el banc, cada línia de comissió s'assigna a un sol pla comptable, el saldo d'ingressos diferits travessa netament la data del tall, i el memoràndum brut-versus-net del teu arxiu d'auditoria cobreix les dues meitats de l'any sota una sola política. Programa el tall en un límit de període, executa les vendes noves a la nova plataforma mentre les subscripcions antigues arriben a la renovació, i mantén el sistema antic llegible fins que els auditors hagin vist l'any de la migració. Fes-ho, i el canvi serà una nota al peu als comptes de l'any vinent en lloc de la variància que ningú sap explicar.

Font: https://beancount.io/ca/blog/2026/11/10/migrating-lemon-squeezy-polar-paddle-merchant-of-record-revenue-recognition-guide

Publicat: 10 de novembre del 2026