Tus pagos de enero llegaron de Lemon Squeezy y tus pagos de agosto llegan de Paddle, y ahora tu contador hace una pregunta que ningún panel de control puede responder por sí solo: ¿cuántos ingresos por suscripción ganaste realmente este año? El proveedor anterior cobraba bajo un esquema de comisiones, una cadencia de pagos y un conjunto de facturas fiscales emitidas desde sus propias entidades. El nuevo proveedor hace el mismo trabajo con informes distintos, líneas de comisión distintas y documentación distinta. Entre ambos hay un saldo de ingresos diferidos, una pila de planes anuales vendidos en una plataforma y atendidos en otra, y un cierre de año que tiene que unir dos libros incompatibles en un conjunto de cuentas creíble. Ese empalme —no la integración de la API, que toma días— es donde las migraciones de merchant of record fallan silenciosamente.
Esta es una decisión viva para miles de vendedores ahora mismo. Stripe adquirió Lemon Squeezy en julio de 2024, y la actualización de Lemon Squeezy de enero de 2026 decía que su futuro es una ruta de migración sencilla hacia Stripe Managed Payments, el propio producto de merchant of record de Stripe. No se ha publicado ninguna fecha límite y Lemon Squeezy sigue funcionando, pero los vendedores que no quieren ser migrados según el calendario de otro están evaluando a los independientes: Paddle y Polar, ambos auténticos merchants of record con la misma tarifa anunciada del 5 por ciento más 50 centavos. Si eres uno de ellos, el cambio de facturación es la parte fácil. Mantener los libros creíbles durante todo ello es el proyecto real.
Qué es realmente un merchant of record en tus libros
Un merchant of record es el vendedor legal de tu producto, no solo tu procesador de pagos. Cuando un cliente compra a través de Paddle, Polar o Lemon Squeezy, el extracto de la tarjeta nombra al proveedor, la factura fiscal se emite desde una de las propias entidades del proveedor, y los registros de impuesto sobre ventas e IVA en Alemania, Japón o Texas pertenecen al proveedor en lugar de a ti. El proveedor calcula, recauda, declara y remite el impuesto, absorbe la responsabilidad de los contracargos y te envía un pago por el resto.
Esa estructura legal decide cómo se ven tus registros contables. La factura al comprador documenta la venta del proveedor a tu cliente — es su factura, no la tuya. Tu lado de la transacción está documentado por registros del lado del vendedor: una factura inversa que describe tu suministro al proveedor y un aviso de remesa que registra cada importe de pago. Tus ingresos son un pago, neto de la comisión del proveedor, que llega según el calendario del proveedor en lugar de continuamente. La versión de esos documentos de cada proveedor se ve distinta, que es exactamente por qué ejecutar dos de ellos en un mismo año divide tus registros en dos.
La decisión bruto-versus-neto que debes tomar una sola vez
Antes de tocar cualquiera de las dos plataformas, resuelve la única política contable que la migración te obliga a defender: ¿reconoces el importe total que pagó el cliente como ingresos (bruto), o solo el pago que recibiste (neto)?
Bajo la ASC 606, esta es la cuestión de principal-versus-agente, y se responde por el control — no por quién emitió la factura ni por el nombre en el extracto de la tarjeta. La guía está en ASC 606-10-55-36 a 55-40: una entidad es principal si controla el bien o servicio especificado antes de transferirlo al cliente, y reporta los ingresos en bruto; si su promesa es solo la de organizar que otra parte los proporcione, la entidad es agente y reporta solo su comisión neta. Para un proveedor de software que vende a través de un merchant of record al estilo de un revendedor, el mismo análisis decide quién es tu cliente. Si tu cliente es el usuario final, los ingresos son el precio del usuario final y la parte del proveedor es un costo de venta por debajo de la línea de ingresos. Si tu cliente es el propio proveedor, los ingresos son el precio que el proveedor te pagó — el pago.
El beneficio bruto es idéntico en ambos casos. Los ingresos reportados no lo son, y ese número alimenta tu tasa de crecimiento, tus múltiplos de ingresos en una ronda de financiación o adquisición, y cada comparación período-a-período que lee tu junta. La mayoría de los proveedores de software que venden a través de marketplaces y revendedores acaban en el tratamiento bruto, pero cualquiera de las dos respuestas es defendible si tu análisis la respalda. Lo que no es defendible es la deriva: registrar los pagos de Lemon Squeezy en neto en la primera mitad del año y los pagos de Paddle en bruto en la segunda mitad porque los informes del nuevo proveedor hacían más fácil el bruto. Elige una política, escribe el análisis de control en un memo que tu auditor pueda leer, y aplícala de forma idéntica a los pagos de ambos proveedores durante todo el año.
Las cinco costuras donde el año se divide en dos
1. Las suscripciones no migran; los clientes se vuelven a suscribir. No hay migración automática de tokens entre procesadores de pago. Las tarjetas guardadas generalmente no se pueden exportar de un merchant of record en forma utilizable, así que prevé que los suscriptores vuelvan a introducir los datos de pago en la nueva plataforma — o confirma por escrito, antes de comprometerte, que el nuevo proveedor puede mover las suscripciones activas y las tarjetas guardadas por ti. Hasta que cada cliente se vuelva a suscribir, la plataforma antigua sigue cobrándoles, lo que significa que los dos sistemas funcionan en paralelo durante meses y el cierre de cada mes concilia dos flujos de pagos.
2. Los precios grandfathered y las anclas de renovación deben reconstruirse a mano. Cada suscripción activa lleva un precio, una fecha de renovación y a menudo un plan grandfathered que ya no se vende. La nueva plataforma no sabe nada de esto hasta que lo recrees: productos, precios, planes heredados que solo tienen los clientes existentes, comportamiento de las pruebas, cupones, reglas de impuestos incluidos y anclas de renovación. Omite un precio grandfathered y a un cliente leal se le cobrará la nueva tarifa — un desastre de soporte que además registra ingresos que luego tienes que revertir.
3. Los planes anuales crean un cutover de ingresos diferidos. Un cliente que compró un plan anual de $1,200 en marzo pagó al proveedor anterior, pero tú ganas ese ingreso mes a mes hasta el febrero siguiente. En la fecha del cutover, parte de ese efectivo aún no se ha ganado, y permanece en tu balance como ingresos diferidos sin importar qué plataforma atienda los meses restantes. Los informes de la nueva plataforma nunca mostrarán ese pasivo — solo conoce las ventas hechas a través de ella — así que la migración debe trasladar el saldo explícitamente o tus ingresos de la segunda mitad quedarán sobreestimados por dinero que ya cobraste.
4. Los reembolsos y contracargos cruzan el cutover. Un reembolso emitido en agosto por una venta hecha en mayo vive en el sistema del proveedor anterior, bajo las reglas de comisión anteriores, mientras que el ingreso que revierte puede que ya se haya reconocido a lo largo de dos trimestres. Cada proveedor absorbe los contracargos como merchant of record, pero los asientos contables — revertir ingresos, registrar cualquier comisión no reembolsable, ajustar el pago que ya recibiste — caen en tus libros, y los informes de ajustes de cada proveedor los formatean de manera distinta.
5. El calendario de pagos, la moneda y la documentación fiscal cambian a la vez. Los calendarios de pagos difieren según el proveedor, así que las ventas de la misma semana pueden caer en extractos bancarios de meses distintos antes y después del cambio. Los vendedores transfronterizos se enfrentan a nuevas líneas de tipos de cambio y nuevos desgloses de comisiones. Y cada proveedor reporta sus propias declaraciones fiscales bajo sus propios registros, mientras que los vendedores estadounidenses pueden recibir informes de pagos separados de cada plataforma durante el año. Ninguno de estos son errores; son dos sistemas correctos que discrepan en formato, y tu cierre tiene que normalizar todos ellos en un único plan de cuentas.
El manual de migración seguro para las finanzas
Trabaja en este orden, y no comprimas la ejecución en paralelo.
1. Fija la fecha de cutover en un límite de periodo. Los cutovers a mitad de mes dividen los periodos de suscripción, la prorrata y los lotes de pagos a través de la costura. Un cutover a fin de mes o de trimestre te da poblaciones limpias de antes y después y un cierre que contiene toda la transición.
2. Congela y exporta todo de la plataforma antigua. Bloquea los periodos contables que el proveedor anterior ya facturó. Exporta el catálogo completo de planes, cada suscripción activa con su precio y fecha de renovación, el historial completo de facturas y cada informe de pagos con desgloses de comisiones. Mantén la cuenta antigua en solo lectura, sin eliminar, durante al menos un ciclo de auditoría completo — los auditores y las autoridades fiscales preguntan sobre el año de la migración específicamente porque esperan la costura.
3. Recrea el catálogo de planes, incluidos los planes que ya no vendes. Los planes heredados y grandfathered deben existir en el nuevo sistema antes de que el primer cliente migrado renueve allí. Documenta cada correspondencia de un ID de plan antiguo a uno nuevo; esa tabla de correspondencias es el rastro de auditoría que explica por qué las facturas de julio se ven distintas de las de junio para el mismo cliente.
4. Pon primero a los nuevos clientes en la nueva plataforma. Ejecuta el nuevo proveedor en paralelo para las nuevas ventas mientras las suscripciones existentes llegan a su renovación en el antiguo, y luego mueve las cohortes en límites naturales — fechas de renovación, fines de mes, nunca a mitad de ciclo. Cada cohorte tiene su propia conciliación antes de que empiece la siguiente. Un cutover de golpe concentra cada fallo de re-suscripción, cada omisión de grandfathering y cada caso límite de prorrata en un único cierre.
5. Mapea ambos informes de pagos en un único plan de cuentas. Antes del primer cierre que incluya a ambos proveedores, construye la traducción: cada línea de comisión, línea de impuesto, ajuste y código de reembolso de cada informe se mapea a una de tus cuentas contables. Los dos proveedores nunca usarán las mismas etiquetas. Sin el mapeo, tu contable lo inventa de forma distinta cada mes.
6. Ajusta explícitamente los ingresos diferidos. Concilia el saldo no ganado plan por plan en la fecha del cutover, y registra cualquier diferencia entre los registros de la plataforma antigua y tu libro como un ajuste explícito con una causa documentada — no como un cuadre forzado. Desde el cutover en adelante, reconoce el saldo restante según lo previsto, independientemente de qué plataforma atienda al cliente.
Cómo se ve el mes del cutover en tu libro
La conexión contable es sencilla una vez que separas a los dos proveedores con un seguimiento de comisiones distinto en lugar de dejar que ambos registren directamente en ingresos. Reconoce cada pago en bruto — el pago completo del cliente como ingresos, la parte del proveedor como gasto de venta — y sigue reconociendo los saldos diferidos anteriores al cutover según su calendario original. La documentación de Beancount cubre la sintaxis del libro usada abajo si algo de esto te resulta desconocido.
Supón que un cliente compró un plan anual de $1,200 a través de Lemon Squeezy a mediados de marzo. El pago de marzo llegó neto de la comisión del 5 por ciento más 50 centavos ($60.50), y para el 30 de junio has reconocido cuatro meses de ingresos ($400), dejando $800 no ganados. El 1 de julio es tu fecha de cutover, y una nueva suscripción mensual de $49 se vende a través de Paddle en julio. En un libro de texto plano eso se ve así:
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 * "Venta de plan anual vía Lemon Squeezy, comprador pagó 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Reconocer porción de junio del plan anual"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Venta de plan mensual vía Paddle, comprador pagó 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Reconocer porción de julio del plan anual previo al cutover"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USDTres detalles sostienen toda la migración. Primero, las comisiones de cada proveedor se registran en su propia subcuenta, así los totales de fin de año muestran exactamente lo que te costó cada plataforma y los dos esquemas de comisiones nunca se mezclan. Segundo, el asiento de reconocimiento de julio para la venta de marzo no cambia con el cutover — los ingresos diferidos son tu pasivo, ganados según tu calendario, y no le importa qué plataforma cobró el efectivo. Tercero, cada asiento se vincula a un informe de pagos específico: el aviso de remesa de Lemon Squeezy de marzo para el primero, el pago de Paddle de julio para el tercero. Cuando tu contador pregunte cómo se ganaron los ingresos del año, cada número apunta exactamente a la documentación de un solo proveedor.
Cierra la costura deliberadamente
Una migración de merchant of record son dos proyectos con un solo nombre: mover la facturación, que tus ingenieros terminan en semanas, y mover los libros, con los que tu contador convive durante un año. El proyecto de facturación termina cuando el último cliente se vuelve a suscribir. El proyecto de los libros termina cuando cada pago de ambos proveedores cuadra con el banco, cada línea de comisión se mapea a un único plan de cuentas, el saldo de ingresos diferidos cruza limpiamente la fecha del cutover, y el memo de bruto-versus-neto en tu archivo de auditoría cubre ambas mitades del año bajo una sola política. Programa el cutover en un límite de periodo, ejecuta las nuevas ventas en la nueva plataforma mientras las suscripciones antiguas llegan a su renovación, y mantén el sistema antiguo legible hasta que los auditores hayan visto el año de la migración. Hazlo así, y el cambio será una nota al pie en los estados financieros del próximo año en lugar de la variación que nadie puede explicar.
